Subject: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.txt

From: [email-masked]
Date: Mon, 21 May 2012 16:40:47 -0700

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/

---

From: Maoke <[email-masked]>
Date: Tue, 22 May 2012 01:54:44 +0000

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 <[email-masked]>

>
> 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.
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 22 May 2012 17:11:19 +0200

Hi Maoke,

Thank you for this quick reaction.

2012-05-22  03:54, Maoke :

> 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 ... 

Yes, the goal remains a single standard, one that combines useful features of MAP-T and MAP-E proposals. 
A complementary explanation in section 7 (Relationship with previous work) can be added to clarify it. 

Besides, if 4rd is retained by the WG for standard track, the word "unified" in the title can be deleted. (It is only a reference to the historical process that led to the specification, the subject of section 7)  

> 1. the new draft remains ipv4 header checksum not end-to-end transparent for ICMP and UDP with zero checksum. 

(*) Assuming that links of 4rd domains have reliable link-layer corruption detections, and that their routers never forward packets that have been corrupted in memory (two acceptable assumptions AFAIK), IPv4 packets forwarded at domain exit have their checksums completely unchanged, unless required for decreased TTL and/or ECN.

> 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.

RFC6145 says "when the translator is configured to forward the packet without a UDP checksum, the fragmented IPv4 UDP packets will be translated". Reason why this is acceptable is AFAIK an assumption similar to (*) above. 

> (=> 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.

Yes encapsulation maintains *all* TTLs, but:
- When MAP-T was proposed as a possible unique standards, this was considered negligible.
- 4rd does much more in this respect than MAP-T.

> (=> can 4rd be called as a unified solution unifying encapsulation?)
> 
> (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.)

In my understanding of MAP-E, TTL decrease isn't more part of the tunnel behavior than in 4rd.
Routers remain responsible for their usual TTL processing, which is appropriate AFAIK.

> 3. TTL=1 and TTL=255 are treated differently may also confuse traceroute. e.g.: 
> 

>    don't you think it is strange? the above behavior is neither encapsulation nor translation,

In the traced route above, IPv4 addresses of intra-domain nodes are all the same (the domain entry IPv4 address, if it exists,  or 192.70.192.254 as per R-22).
This provides a way to detect that a v4/v6 tunnel has been used, with an indication of the number traversed nodes, IMHO a useful feature.

Regards,
RD

> then can we call it as a "unification"?
>

---

From: Maoke <[email-masked]>
Date: Wed, 23 May 2012 01:29:10 +0900

dear Remi,

thanks a lot for your clarification.

only some quick reaction with my personal observations:

1. it is not the time to compare 4rd with MAP-T or with MAP-E separately,
but with the MAP-suite. i never think MAP-T is intended to be
the *unique* standard in the scope of residual deployment. (maybe it "was"
but we'd better discuss things based on current understanding)

2. doing much more != doing better correct. a) the "useful feature" of
showing number of traverse nodes has been offered by MAP-suite through
translation mode. is it really an add-on to the encapsulation? i don't
think so. sometimes provider would like to open the tunnel details to the
users sometimes they do like to hide the secret. 4rd traceroute
behavior forces operator doing the latter. i don't know if everyone like
it. i don't anyway. b) the TTL security mechanism is still a problem. c) i
said that traceroute behavior is strange, it doesn't mean there are several
IPv6 responders. it means there are BR showed twice. and one think 3 hops
can reach the BR but 4 hops cannot reach the host C soon next to the BR.
this is the strange thing!

3. regarding the link layer assumption, either MAP-T or MAP-E doesn't need
such an assumption. (new assumption is new limitation on usability scope to
my understanding). and i have pointed out it is not a correct understanding
to think things would be reliable as long as link layer is reliable.

for detailed investigation on these above observations, i promise i will
update the commetary draft to reflect them. but not very quick as i got my
hands hurt by the mouse and keyboard recently. :P anyway i am happy that
you make the design not touching the first bit of Hop Limit now. thanks!

regards,
maoke
2012/5/23 Rémi Després <[email-masked]>

> > 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.
> >
> Besides, if 4rd is retained by the WG for standard track, the word
> "unified" in the title can be deleted. (It is only a reference to the
> historical process that led to the specification, the subject of section 7)
>
>
> for ICMP and UDP with zero checksum.
>
> (*) Assuming that links of 4rd domains have reliable link-layer corruption
> detections, and that their routers never forward packets that have been
> corrupted in memory (two acceptable assumptions AFAIK), IPv4 packets
> forwarded at domain exit have their checksums completely unchanged, unless
> required for decreased TTL and/or ECN.
>
> > 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.
>
> RFC6145 says "when the translator is configured to forward the packet
> without a UDP checksum, the fragmented IPv4 UDP packets will be
> translated". Reason why this is acceptable is AFAIK an assumption similar
> to (*) above.
>
>
> > 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.
>
>
> > (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.)
>
> encapsulation nor translation,
>
>
> In the traced route above, IPv4 addresses of intra-domain nodes are all
> the same (the domain entry IPv4 address, if it exists,  or 192.70.192.254
> as per R-22).
> This provides a way to detect that a v4/v6 tunnel has been used, with an
> indication of the number traversed nodes, IMHO a useful feature.
>
> Regards,
> RD
>
>
>
>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 22 May 2012 13:28:09 -0400

On 2012-05-22 12:29, Maoke wrote:
> 1. it is not the time to compare 4rd with MAP-T or with MAP-E
> separately, but with the MAP-suite. i never think MAP-T is intended
> to be the *unique* standard in the scope of residual deployment. (maybe
> it "was" but we'd better discuss things based on current understanding)

My understanding: 4rd is a compromise.

What you gain: only one protocol to consider.
What you lose: some edge cases are not supported.

So any argument to the effect that "MAP-E|T does X and 4rd doesn't" is 
empty. This is expected, it's a compromise.

The argument should be: "I need 4rd to do X because ..."

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: GangChen <[email-masked]>
Date: Wed, 23 May 2012 14:19:00 +0800

> it. i don't anyway.

I guess translation mode may not help you to reveal the secret either.

RFC6145 says
"  Note that the IPv6 addresses in the IPv6 header may not be IPv4-
   translatable addresses and there will be no corresponding IPv4
   addresses representing this IPv6 address.  In this case, the
   translator can do stateful translation.  A mechanism by which the
   translator can instead do stateless translation of this address is
   left for future work."

Stateful translator seems to me a shared IPv4 address might be used
for several traversed nodes.

b) the TTL security mechanism is still a problem.

Please kindly to identify the issue.

Gang

> c) i
>> Yes, the goal remains a single standard, one that combines useful
>> features
>> of MAP-T and MAP-E proposals.
>> A complementary explanation in section 7 (Relationship with previous
>> work)
>> can be added to clarify it.
>>

---

From: Maoke <[email-masked]>
Date: Wed, 23 May 2012 08:49:06 +0000

2012/5/23 GangChen <[email-masked]>

> I guess translation mode may not help you to reveal the secret either.

open (some) details != reveal (all) secrets.
it is "i don't care if you get to know" or "i am happy to let you know",
rather than "i have to let you know".

we were talking about that 4rd disables operator's right of protecting
their secret rather than the right of revealing it. revealing the secret,
we have a lot of ways, not necessarily through user's traceroute.

but you hinted me to find that 4rd's traceroute behavior is really a little
worse than RFC6145. see the detailed example of path below:

   A - B - CE - D(v6) - F(v6) - G(v6) - BR - I - J

from A to J:
TTL = 1 => B responds;
      2 => CE responds;
      3 => BR responds (as TTL_1 set at CE);
      4 => F(woops!! D is skipped) responds
      5 => G responds
      6 => BR responds again
      7 => I responds
      8 => J responds

well, it would be not so bad if all the community of Internet engineers
like such a cute joke.

> Please kindly to identify the issue.

eBGP multihop applies non-1 non-255 values for the hop-limited security of
the sessions. both Cisco and Juniper has this well-known functionality.
iptables can be set with ttl module to restrict only packets with ttl
higher than or less than or equal to a certain value (surely not possible
to be 1 or 255) can be accepted or forwarded. of course, 255 is the most
important value and normative to RFC5082 but it is not the only value in
practical use.

- maoke

---

From: Maoke <[email-masked]>
Date: Wed, 23 May 2012 18:24:21 +0900

2012/5/23 Maoke <[email-masked]>

> to be 1 or 255) can be accepted or forwarded. of
>

typo... *not possible to be 1 or 255* => not necessarily to be 1 or 255..

> course, 255 is the most important value and normative to RFC5082 but it is
> not the only value in practical use.
>
> - maoke
>
>

---

From: GangChen <[email-masked]>
Date: Wed, 23 May 2012 19:24:19 +0800

> we have a lot of ways, not necessarily through user's traceroute.

That is little bit misleading.
I'd rather to understand 4rd provides the tunnel solution with
revealing capability. Operators who want to protect their secrets
could simply disable traceroute on the node.

> well, it would be not so bad if all the community of Internet engineers

I don't see the harm when a solution provides a determinated way to debug.

> important value and normative to RFC5082 but it is not the only value in

The design is following normative behavior.
When you are concerning about numerous implementation variants, the
best answer is PLEASE BE consistent with normative recommendation.

Gang

>> >> historical process that led to the specification, the subject of
>> >> section
>> >> 7)
>> >>
>> >>
>> >> In my understanding of MAP-E, TTL decrease isn't more part of the
>> >> tunnel
>> >> behavior than in 4rd.
>> >> >        Title           : IPv4 Residual Deployment via IPv6 - a
>> >> > unified
>> >> Stateless Solution (4rd)
>> >> >        Author(s)       : Remi Despres
>> >> >                          Reinaldo Penno
>> >> >                          Yiu Lee
>> >> >                          Gang Chen
>> >> >                          Sheng Jiang

---

From: Rémi Després <[email-masked]>
Date: Wed, 23 May 2012 14:25:35 +0200

Maoke,

Thanks for the thorough analysis of how 4rd deals with the various TTL value.

2012-05-23 10:49, Maoke:

> it is "i don't care if you get to know" or "i am happy to let you know", rather than "i have to let you know". 
> 
> we were talking about that 4rd disables operator's right of protecting their secret rather than the right of revealing it. revealing the secret, we have a lot of ways, not necessarily through user's traceroute. 
> 
> but you hinted me to find that 4rd's traceroute behavior is really a little worse than RFC6145.

For TTL = 255 and TTL = 1, isn't 4rd now BETTER than RFC6145? 
(Thanks for your previous remarks that contributed to improve support of these values.) 

Regarding other values, more comments below.

> see the detailed example of path below: 
>             

This interesting example suggests IMHO to simplify R-22 to avoid permitting multiple behaviors. R-22 would just say "192.70.192.254 MUST be used as source address" instead of "If the CE or BR has a global IPv4 address, this address MUST be used as source of this packet.  Otherwise, 192.70.192.254 SHOULD be used as this source".

With this, we have:
 
TTL = 1 => B responds 
      2 => CE responds
      3 => BR responds  
      4 => F responds in v6 
           CE responds to A, SRC=192.70.192.254
      5 => G responds in v6
           CE responds to A, SRC=192.70.192.254
      6 => BR responds
      7 => I responds 
      8 => J responds

Thus, where a 4rd tunnel is traversed, trace route gets:
- two responses of the tunnel exit node
- between these two, as many responses with SRC=192.70.192.254 as there are intermediate IPv6 routers
This is a feature I see no reason to avoid or regret.

> well, it would be not so bad if all the community of Internet engineers like such a cute joke.

For at least SOME Internet engineers, this as a feature, not as a joke ;-) . 

> eBGP multihop applies non-1 non-255 values for the hop-limited security of the sessions. both Cisco and Juniper has this well-known functionality. iptables can be set with ttl module to restrict only packets with ttl higher than or less than or equal to a certain value (surely not possible to be 1 or 255) can be accepted or forwarded.

AFAIK, this functionality does work across a 4rd domain. 
Any real case where this would be a problem?

RD

> of course, 255 is the most important value and normative to RFC5082 but it is not the only value in practical use.
> 
> - maoke 
>  
> 
> 
> 
> Gang
> 
> 
> 
> > c) i