hi Remi and other authors,
thanks a lot for updating the draft. semantics review will follow and here
i only make an incomprehensive but quick response. please don't hesitate to
point out if i misunderstand.
i assume that the purpose of 4rd (this 4rd = 4rd-U in the past,
conceptually) is still unchanged as it is titled: making a unified solution
of encapsulation and translation for ipv4 residual deployment in an ipv6
domain. then i would like to clarify that ...
1. the new draft remains ipv4 header checksum not end-to-end transparent
for ICMP and UDP with zero checksum. even though the CNP in address could
protect the integrity of addresses, the integrity protection provided by
full encapsulation for port number and payload length is still lost. (=>
can 4rd be called as a unified solution unifying encapsulation?)
2. end-to-end transparency for TTL=1 and TTL=255 is now protected but other
values are not. i doubt this is enough, because neither RFC4271 nor RFC5082
is limited to the case only 1 or 255 is applied for the TTL security
mechanism. in practice, eBGP sessions across 1 hop, 2 hops, or several hops
are possible and the BGP speaker may not be very next to the CE nor to the
BR. we noticed that full encapsulation protect any case of TTL. (=> can 4rd
be called as a unified solution unifying encapsulation?)
but it is good that the first bit of IPv6 Hop Limit is now not misused.
(btw, a minor point of confusion, if TTL_1 = 1, i suppose the IPv6-to-IPv4
translator should make TTL=0 in the resulted packet; if TTL_255 = 1, it
must result in TTL=254, right? as the virtual link has been a hop.)
3. TTL=1 and TTL=255 are treated differently may also confuse traceroute.
e.g.:
A - B - CE --(IPv6 domain)-- BR - C
when one do tranceroute at A to C, it will result in:
1 xxx ms xxx ms xxx ms B
2 xxx ms xxx ms xxx ms CE
3 xxx ms xxx ms xxx ms BR
4 xxx ms xxx ms xxx ms (Somewhere in the IPv6 domain)
5 xxx ms xxx ms xxx ms (Somewhere else in the IPv6 domain)
.
.
.
N xxx ms xxx ms xxx ms BR (woops, again, is it a routing loop?)
N+1 xxx ms xxx ms xxx ms C (IPv6-domain hops are counted)
don't you think it is strange? the above behavior is neither
encapsulation nor translation, then can we call it as a "unification"?
thanks a lot for your attention,
- maoke
2012/5/21 <internet-dra...@ietf.org>
>
> 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 : IPv4 Residual Deployment via IPv6 - a unified
> Stateless Solution (4rd)
> Author(s) : Remi Despres
> Reinaldo Penno
> Yiu Lee
> Gang Chen
> Sheng Jiang
> Filename : draft-ietf-softwire-4rd-00.txt
> Pages : 40
> Date : 2012-05-16
>
> The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment
> possible via IPv6 networks without maintaining for this per-customer
> states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of
> 6rd). To cope with the IPv4 address shortage, customers can be
> assigned IPv4 addresses with restricted port sets. In some
> scenarios, 4rd-capable customer nodes can exchange packets of their
> IPv4-only applications via stateful NAT64s that are upgraded to
> support 4rd tunnels (in addition to their IP/ICMP translation of
> [RFC6145]).
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.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-4rd-00.txt
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
