Subject: [Softwires] I-D Action: draft-ietf-softwire-public-4over6-05.txt

From: [email-masked]
Date: Mon, 25 Feb 2013 07:10:56 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Softwires Working Group of the IETF.

	Title           : Public IPv4 over IPv6 Access Network
	Author(s)       : Yong Cui
                          Jianping Wu
                          Peng Wu
                          Olivier Vautrin
                          Yiu L. Lee
	Filename        : draft-ietf-softwire-public-4over6-05.txt
	Pages           : 13
	Date            : 2013-02-25

Abstract:
   When the service provider networks are upgraded to IPv6, end users
   will continue to demand IPv4 connectivity.  This document proposes a
   mechanism for hosts or customer networks in IPv6 access network to
   build bidirectional IPv4 communication with the IPv4 Internet.  The
   mechanism follows the hub and spokes softwire model, and uses IPv4-
   over-IPv6 tunnel as basic method to traverse IPv6 network.  The bi-
   directionality of this IPv4 communication is achieved by explicitly
   allocating public IPv4 addresses to end users, as well as maintaining
   IPv4-IPv6 address binding on the border relay.  This mechanism
   features the allocation of full IPv4 address over IPv6 network, and
   has been used in production for high-end IPv4 users, IPv6 transition
   of ICPs, etc.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-softwire-public-4over6-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-public-4over6-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 27 Feb 2013 09:30:56 +0000

Introduction - the first paragraph needs some revision.

"Experiences from initial IPv6 deployments indicate that transitioning
   a network providers' domain fully to IPv6 requires not only the
   continued support of legacy IPv4 users connected to the boundary of
   that domain, allowing IPv4 address sharing, but also the need for
   carrying out IPv6-only operational practices in that domain [, also
<<<<<< Fragmented & doesn¹t make sense.
   for traffic from IPv4 users.  "

The below sentence needs revision, I don¹t really understand what the
sentence is trying to convey.
Is it saying IP encapsulation overhead is unacceptable or causes issues or
what?

"The translation mode is
   required for environments where the IP encapsulation overhead or IPv6
   traffic interaction & processing (eg use of IPv6 only servers)
   requirements, or both, make the use of the encapsulation solution not
   attractive."

Section 4 - Architecture

would be required if the said IPv6 devices are expected to themselves to
initiate
s/expected to themselves to initiate/expected to initiate

A standard stateless NAT64 function [RFC6145] is extended to allow
      stateless mapping of IPv4 and transport layer port ranges to IPv6
      address space

s/mapping of ipv4 and /mapping of IPv4 address and

Section 6.2

"layer destination port number is in the range configured by MAP for
   the CE and the CE SHOULD drop any non conforming packet"

Why is this drop a SHOULD instead of a MUST? It doesn¹t seem to make any
sense to process a packet that is not
destined to its port range, does it?

"The resulting IPv4 packet is then forwarded to the CE's
   NAPT function, when this is enabled,"

In section 6.1, the NAPT function is referred to as NAT44 function, in
section 6.2 it is referred to as NAPT function.
Can you make the terminology consistent - use either one or the other.

Section 6.2 " When the NAPT function is not enabled". A similar sentence
is needed in section 6.1,
on how to handle the ipv4 packets when NAPT is not enabled

Section 7
"ICMP preserving the ID field on its way to an IPv4 destination."

s/on its way to/on its way back to

"In all other cases, the MAP-T BR MUST derive the destination IPv6 address
by
   simply mapping the destination IPv4 address without additional port
   info."

What are the other cases ? How can you derive the destination IPv6 address
without the port information?
I assume you are talking about the ICMP errors as it is addressed
separately later in the section.
I would suggest clarifying what the other cases are here.

Thanks
Senthil