[Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-01.txt
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 : Motivations for Stateless IPv4 over IPv6 Migration Solutions Author(s) : Mohamed Boucadair Satoru Matsushima Yiu Lee Olaf Bonness Isabel Borges Gang Chen Filename: draft-ietf-softwire-stateless-4v6-motivation-01.txt Pages : 16 Date: 2012-02-10 IPv4 service continuity is one of the most pressing problems that must be resolved by Service Providers during the IPv6 transition period - especially after the exhaustion of the public IPv4 address space. Current standardization effort that addresses IPv4 service continuity focuses on stateful mechanisms. This document elaborates on the motivations for the need to undertake a companion effort to specify stateless IPv4 over IPv6 approaches. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-stateless-4v6-motivation-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-stateless-4v6-motivation-01.txt ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
Dear WG members, I would like to close this document so that we can meet the following item from the WG Charter: 4. Developments for stateless legacy IPv4 carried over IPv6 - develop a solution motivation document to be published as an RFC - develop a protocol specification response to the solution motivation document; this work item will not be taken through Working Group last call until the solution motivation document has been published or approved for publication Except the a comment asking to include a new section to compare stateful vs. stateless, no further comments have been received. I didn't considered adding the proposed new section because IMO it is out of scope of this document. That section can justify in its own a dedicated draft. As for the next step, I see two options: (1) Either issue a WG LC, or (2) Withdraw the document and update the WG charter. WG members, please advise. Cheers, Med ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] MAP and 4rd - Relationship with Single translation
Hi Xing, Good to have you coming in the (unfinished) technical analysis. I answered to Ole on his remarks, which you support, but not on the following: You propose to have a line on IPv4 to IPv6 communication (single translation) supported, wit Let me therefore reiterate the wish to see an ISP use case, with its Mapping rules, and with IPv6 prefixes of CEs that illustrate the problem you see. Regards, RD Le 2012-02-10 à 04:28, Xing Li a écrit : ... | | | | | | 5 | IPv6 web caches work for IPv4| Y | N | Y | N | || packets | | | | | suggest you rename to IPv4 to IPv6 communication (single translation) supported (2) More clarification should be added here. I am not sure 4rd-H can support single translation. (a) According to (1), 4rd-H does not perform header translation defined by RFC6145. (b) In the softwire mailing list, it seems that 4rd-H cannot support single translation. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts. (c) If 4rd-H cannot support single translation, then IPv6 web caches work for IPv4 packets requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets. ... (5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts. Please add | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | ... ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] MAP and 4rd - Feature comparison table
Le 2012-02-10 à 15:25, Ole Trøan a écrit :
Remi,
New version, after a discussion with Ole:
++--+-+-+-+-+
|| Feature (based on CURRENT drafts)| MAP | MAP | 4rd | 4rd |
|| | -T | -E | -H | -E |
++--+-+-+-+-+
| 1 | Full Transparency to IPv4 DF bit | N | Y | Y | Y |
|| | | | | |
| 2 | ISP can impose a Tunnel traffic | N | Y | Y | Y |
|| class| | | | |
|| | | | | |
| 3 | Possible support of CEs behind | N | N | Y | Y |
|| third-party CPEs | | | | |
possible with MAP-{E,T} too, but may require coordination of subnet
numbering.
Your describing what you have in mind would be useful.
So far I see the 4rd-U approach as the only specified one that is viable.
MAP uses the first subnet of a End-user IPv6 prefix. to deploy a MAP CE
behind another IPv6 CE, the only thing required is to route the prefix (/64)
used for MAP to this CE.
both 4rd-u and MAP assume that prefix assignment with multiple routers is
solved, and that some other mechanism exists for provisioning.
I don't see the point of having text in the specification for this use case.
it is a deployment option.
I plan to have sometime a separate thread on this one, not technically trivial
AFAIK.
in all solutions will require a different provisioning model.
Not sure what you mean.
Anything missing in 4rd-U in this respect?
|| | | | | |
| 4 | IPv6 port-based ACLs work for IPv4 | Y | N | Y | N |
|| packets | | | | |
suggest we rename this to IPv6 features can be applied to the payload
packet?
(we're talking about applying features in between the translators/tunnel
endpoints here).
The point being true, I don't see a need to change it.
What you propose is less precise, and IMHO consequently less useful.
there are many more features than just ACLs.
The point being only both true and operationally differentiating, its presence
here is AFAIK justified.
you are misleading when stating that the IPv6 ACLs work on IPv4 packets. they
don't.
I wrote port-based ACLs, never claimed it for all IPv6 ACLs.
you could also add a new feature:
possible to apply IPv4 features on the payload
Don't understand what it means in practice.
a reason for T is to be able to apply native IPv6 features in the network.
given that there is a feature gap between IPv4 and IPv6 support in existing
gear, where IPv4 features are better supported. then an E solution could
allow IPv4 features to be applied to tunnel packets. in practice:
pak-network_start += 40.
apply IPv4 features to inner packet
pak-network_start -= 40
You may find that the point is minor, but it remains: some deployed products
aren't ready yet to do what you suggest yet, and no announced availability date
and/or price.
The point was made at the Beijing meeting, and has not been denied since then,
AFAIK.
which is possible if IPv4 features are enhanced to support offset the
tunnel encap header.
so:
| 4.1 | IPv6 features can be applied to the payload packet | Y | N | Y |
N|
| 4.2 | IPv4 features can be applied to the payload with | N | Y | N |
Y|
| | tunnel vision
|| | | | | |
| 5 | IPv6 web caches work for IPv4| Y | N | Y | N |
|| packets | | | | |
suggest you rename to IPv4 to IPv6 communication (single translation)
supported
With any interpretation I can imagine of of what you write, I see this as a
different point.
OTOH, I acknowledge that there is a point worth analysing about the
relationship with single translation.
More about this in my forthcoming answer to Xing.
can a T session terminate in a native unchanged IPv6 host? as long as this
host has an IPv6 MAP address?
that is single translation. and implies that T packets leak into the native
network. examples of use cases for this is web caching, captive portals, or
just providing IPv4 access to IPv6 only servers.
given the wider scope, your feature name is not sufficient.
As answered to Xing Li, this point of relationship with single translation
deserves IMHO its own thread (not technically trivial AFAIK.
|| | | | | |
| 6 | No constraint on host addresses or | N | N | Y | Y |
|| subnet prefixes in CE sites (V-octet | | | | |
|| format)
