DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients
RFC 7598

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    softwire mailing list <softwires@ietf.org>,
    softwire chair <softwire-chairs@tools.ietf.org>
Subject: Protocol Action: 'DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients' to Proposed Standard (draft-ietf-softwire-map-dhcp-12.txt)

The IESG has approved the following document:
- 'DHCPv6 Options for configuration of Softwire Address and Port Mapped
   Clients'
  (draft-ietf-softwire-map-dhcp-12.txt) as Proposed Standard

This document is the product of the Softwires Working Group.

The IESG contact persons are Brian Haberman and Ted Lemon.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp/


Technical Summary

   This document specifies DHCPv6 options, termed Softwire46 options,
   for the provisioning of Softwire46 Customer Edge (CE) devices.
   Softwire46 is a collective term used to refer to architectures based
   on the notion of IPv4 Address+Port (A+P) for providing IPv4
   connectivity across an IPv6 network.

Working Group Summary

  The working group had active discussion on the draft and the current
  text of the draft is representative of the consensus of the working
  group. This document was a result of merging DHCPv6 options 
  required for several softwire solutions into a single document and
  rationalizing them after consolidating similar options and removing
  duplicates. 

Document Quality

  There is an open source implementation of these options in the recently
  released OpenWRT software (the BARRIER BREAKER release). There 
  are also available implementations of the mechanism specific options
  that got merged into this draft.

Personnel

Suresh Krishnan is the document shepherd. Ted Lemon is the responsible
AD.

RFC Editor Note

This document makes frequent use of the term "sub-option", which is incorrect according to RFC 7227, section 9.   The correct term is "encapsulated option."   Please double-check that all such uses are corrected.   Thanks!

This document is one of a set of five softwire documents that should be published with sequential RFC numbers.  The numbering should be in the following order:

draft-ietf-softwire-lw4over6
draft-ietf-softwire-map
draft-ietf-softwire-map-dhcp
draft-ietf-softwire-map-t
draft-ietf-softwire-4rd