Incorporating (opposing) comments from the softwire and DHC wg's; 1) Servers MUST send one option relaxed to SHOULD, on the basis that current DHCPv6 server implementations don't have a control for how many instances of "new options" (defined after the software is released) may be configured or sent.
2) Introduction of a new term, a "B4 system", which is the amalgamation of the B4 element we are configuring and any other software co-resident (specifically the DHCPv6 client or other configuration management layers). Several normative specifications are changed to refer to the B4 system instead of "the client" which could otherwise be seen to require a change in software implementation of DHCPv6 clients specifically - we don't want that. Either the DHCPv6 client, the B4 element, or some software joining the two in the middle need to validate that only one domain name is being used, and we don't care which one. ---------- Forwarded message ---------- From: IETF I-D Submission Tool <[email protected]> Date: Fri, Jan 21, 2011 at 1:46 PM Subject: New Version Notification for draft-ietf-softwire-ds-lite-tunnel-option-08 To: [email protected] Cc: [email protected] A new version of I-D, draft-ietf-softwire-ds-lite-tunnel-option-08.txt has been successfully submitted by David Hankins and posted to the IETF repository. Filename: draft-ietf-softwire-ds-lite-tunnel-option Revision: 08 Title: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Creation_date: 2011-01-21 WG ID: softwire Number_of_pages: 8 Abstract: This document specifies a DHCPv6 option which is meant to be used by a Dual-Stack Lite Basic Bridging Broadband (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR). The IETF Secretariat. -- David W. Hankins SRE Google, Inc.
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
