![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Hi,
From what I understood during today's meeting discussion, there are 2 goals that we are trying to achieve:
- Standarized option is urgently needed, so we should not prolong the discussion more than necessary
- Generic purpose tunneling and encapsulation approach was discussed before without any noticeable agreements
We have basically 2 proposals (Another proposed option mentioned in draft-townsley-ipv6-rd6-00 is designed for DHCPv4, thus not applicable for this discussion):
There is also certain confusion regarding the sc-discovery draft. -00 was presented during meeting, but there is -01 version available. The only noticeable change is Protocol Type field being extended to 16 bits and ETHER-TYPE values are used.
�
Taking into consideration that there was a comment by an Internet Area
Director that DHCPv4 options specification is no longer a priority, I propose
to continue working on Dual-Stack Lite option, but to use some ideas from SC
Discovery option. As dual-stack lite is a IPv4/IPv6 only, there is no need to
specify tunnel type. Also, this will avoid confusion for vendors if there are multiple encapsulations required. No, there is just single one: IPv4/IPv6 only.
Should more generic tunneling configuration mechanism become required, additional suboptions may be defined in the future.
�
What are group's thoughts regarding that matter?
�
If there is a contributting co-author position available, I would be happy to volunteer.
�
Regards,
Tomek