Subject: [Softwires] 4rd-u behavior in dynamic routing

From: Maoke <[email-masked]>
Date: Mon, 26 Mar 2012 22:48:39 +0900

dear Remi,

i think you won't be against if i change the subject of this specific
discussion, focusing on the routing issues regarding virtual link.
2012/3/26 Rémi Després <[email-masked]>

> Different understanding.
>> An detailed E use case that cannot be supported by U (if it exists) would
>> give substance to this claim.
>> Open to look at it.
>>
>
> in my personal experience i could give you at least three quick examples
> of the use case for the building block of "virtual link":
>
> first example, if the IPv4 customer network plays BGP over IPv4 with the
> provider, through the BGP session between CE and BR, a virtual link is
> desired.
>
>     (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4
> world)
>
>
> I don't see in this scenario why anything that works with E (i.e. between
> CEs and BRs) wouldn't also work with U.
>
>

by default, ebgp requires direct link (some implementations specify TTL = 1
to achieve this). U decreases TTL when packet goes through IPv6 cloud, and
therefore CE---BR ebgp session cannot be established with regular BGP
configurations.

> second example, there are dynamic routing protocols like RIP running in
> the following (multihoming) topology for IPv4 routing. the operator may
> want to treat the CE-BR as a single hop in order the virtual link is
> considered the distance vector calculation.
>
>     (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4
> world)
>                \                                                        /
>                 \                                                      /
>                  +------------ CE ----(Another, IPv4 domain)----------+
>
>
> Same comment.
>
>

similar misunderstanding. RIP distance vectors are delivered to
neighbors but the operators are easy to be confused by the fact that
CE---BR are shown as multihop with tools like traceroute.

>
>
> third example, same topology as above but OSPF are applied, and OSPF
> TTL-security check are enabled to ensure hop-passings less than a specified
> threshold. if the operator would like to treat CE---(IPv6-only domain)---BR
> as one hop because it is considered as virtual link, 4rd-u's rudiness in
> decreasing TTL will hurt.
>
>
> Same comment.
>
>

same misunderstanding. without knowing the details of the IPv6 domain
backbone, it is difficult for the operator to set up a proper value of the
TTL-security parameter for the OSPF regarding the CE---BR section. virtual
link (full encapsulation) eliminates this trouble.

>
>
> MAP-E (and other E) surely has no limitation in supporting any features of
> existing routing protocols.
>
>
> Why U would be less transparent between CEs and BRs than E for any L4
> protocol remains unexplained.
>
>

hope the above helps. it is not about the transparency but about the
behavior of virtual link. it is not about any L4 protocol but about routing
protocols.

>
>
>
> with at least the above three examples, i conclude "U cannot replace E at
> all"!
>
>
> See above.
>
>

see above.

- maoke

>
>
> (btw, surely the translation has the same limitation not to support the
> above features but, e.g., as you also said, it opens transport-layer stuff
> to the middle boxes). therefore i said operators may use either
> encapsulation or translation according to what they attach importance to.)
>
>

---

From: Maoke <[email-masked]>
Date: Tue, 27 Mar 2012 00:38:21 +0000

dear Remi,

i know you are very busy in Paris, but please respond to this thread.
again, if i made anything wrong, please don't hesitate to point out.
thanks!

best,
maoke

2012/3/26 Maoke <[email-masked]>

>>> An detailed E use case that cannot be supported by U (if it
>>> exists) would give substance to this claim.
>>> Open to look at it.
>>>
>>
>>     (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR
>> ----(IPv4 world)
>>
>>
> by default, ebgp requires direct link (some implementations specify TTL =
> 1 to achieve this). U decreases TTL when packet goes through IPv6
> cloud, and therefore CE---BR ebgp session cannot be
> established with regular BGP configurations.
>
>>     (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR
>> ----(IPv4 world)
>>                \                                                        /
>>                 \                                                      /
>> MAP-E (and other E) surely has no limitation in supporting any features
>> of existing routing protocols.
>>
>>

---

From: Rémi Després <[email-masked]>
Date: Tue, 27 Mar 2012 07:43:44 +0200

Le 2012-03-27 à 02:38, Maoke a écrit :

> dear Remi, 
> 
> i know you are very busy in Paris,

Indeed.

> but please respond to this thread.

Response coming.
Could you be less impatient? (There is also a night here, which is time to rest!)

RD

> again, if i made anything wrong, please don't hesitate to point out. thanks! 
> 
> best,
> maoke
> 
> i think you won't be against if i change the subject of this specific discussion, focusing on the routing issues regarding virtual link. 
>> An detailed E use case that cannot be supported by U (if it exists) would give substance to this claim.
>> Open to look at it.  
>> 
>> in my personal experience i could give you at least three quick examples of the use case for the building block of "virtual link": 
>> 
>> first example, if the IPv4 customer network plays BGP over IPv4 with the provider, through the BGP session between CE and BR, a virtual link is desired. 
>> 
>>     (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4 world) 
> 
> I don't see in this scenario why anything that works with E (i.e. between CEs and BRs) wouldn't also work with U.
>  
>  
> by default, ebgp requires direct link (some implementations specify TTL = 1 to achieve this). U decreases TTL when packet goes through IPv6 cloud, and therefore CE---BR ebgp session cannot be established with regular BGP configurations.
>> second example, there are dynamic routing protocols like RIP running in the following (multihoming) topology for IPv4 routing. the operator may want to treat the CE-BR as a single hop in order the virtual link is considered the distance vector calculation.
>> 
>>     (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4 world) 
>>                \                                                        /
>>                 \                                                      /
> similar misunderstanding. RIP distance vectors are delivered to neighbors but the operators are easy to be confused by the fact that CE---BR are shown as multihop with tools like traceroute.
>  
>  
>> third example, same topology as above but OSPF are applied, and OSPF TTL-security check are enabled to ensure hop-passings less than a specified threshold. if the operator would like to treat CE---(IPv6-only domain)---BR as one hop because it is considered as virtual link, 4rd-u's rudiness in decreasing TTL will hurt. 
> 
> Same comment.
>  
>  
> same misunderstanding. without knowing the details of the IPv6 domain backbone, it is difficult for the operator to set up a proper value of the TTL-security parameter for the OSPF regarding the CE---BR section. virtual link (full encapsulation) eliminates this trouble.
>  
>  
> 
>> MAP-E (and other E) surely has no limitation in supporting any features of existing routing protocols.
> 
> Why U would be less transparent between CEs and BRs than E for any L4 protocol remains unexplained.
>  
>  
> hope the above helps. it is not about the transparency but about the behavior of virtual link. it is not about any L4 protocol but about routing protocols.
>  
>  
>  
>> with at least the above three examples, i conclude "U cannot replace E at all"!
> 
> See above.
>  
>  
> see above.
>  
> - maoke
>  
>  
> 
>> (btw, surely the translation has the same limitation not to support the above features but, e.g., as you also said, it opens transport-layer stuff to the middle boxes). therefore i said operators may use either encapsulation or translation according to what they attach importance to.) 
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 27 Mar 2012 07:43:50 +0200

Dear Maoke,

Thanks for clarifying what you meant.
I now understand that you were referring to applications that might require IPv4 dialogue between one link apart nodes.

Whether this is a real use case in the MAP-4rd context remains however to be seen.
Here are my immediate comments:
a) This wasn't mentioned as one of the desirable features of stateless solutions.
b) Since MAP-T can't satisfy such a requirement, and there has been promoters of MAP-T as a sufficient standard, this casts some doubt or reality of this requirement.
c) If the requirement is nevertheless confirmed, it can be satisfied AFAIK by an ad hoc complement to 4rd-U. (At least one one approach I see consists in using the 7 remaining bits of IPv6 packet IDs for this). I would be glad to share w details with you, but only after the WG would confirm that there is a real need. (Let's not say that because there is a solution there is a need.)
d) I didn't see any reference to TTL = 1 in the EBGP of RFC2260. Do you know a better reference than this RFC?

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Tue, 27 Mar 2012 06:41:45 +0000

dear Remi,

sorry but i forgot the time difference this morning. thanks for the quick
response!

2012/3/27 Rémi Després <[email-masked]>

> I now understand that you were referring to applications that might
> require IPv4 dialogue between one link apart nodes.
>

if 4rd-u is limited to a very constrained scope, it is no problem. but
people surely want to have a scalable solution. i listed issues of both
inter-domain and intra-domain routing and i believe supporting some dynamic
routing in the MAP domain is a natural requirement.

> a) This wasn't mentioned as one of the desirable features of stateless

any encapsulation is commonly, well understood to have such a feature
without need of further explanation, without need of adding any elements in
standard. we are now seldom discussing about the routing issue in the
stateless solutions but we cannot block up the road to the real operation.

> b) Since MAP-T can't satisfy such a requirement, and there has been
> promoters of MAP-T as a sufficient standard, this casts some doubt or
> reality of this requirement.
>

well, my predicted response from you. :) please NOTE: MAP-T has never said
it can "replace E". this thread is about the importance of virtual link as
an architectural building block that 4rd-u cannot offer. MAP-T has none of
business with this topic, because it is never considered virtual link. what
i am arguing against, in this thread, is that "once operator has U it
doesn't need either E or T". my point here is: 4rd-u cannot replace MAP-E,
and accordingly the statement "4rd-u is a unified solution" is NOT
qualified.

it is not the topic of this thread if 4rd-u can replace MAP-T or not. i
will go deep in that later, in another thread.

> c) If the requirement is nevertheless confirmed, it can be satisfied AFAIK
> by an ad hoc complement to 4rd-U. (At least one one approach I see consists
> in using the 7 remaining bits of IPv6 packet IDs for this). I would be glad
> to share w details with you, but only after the WG would confirm that there
> is a real need. (Let's not say that because there is a solution there is a
> need.)
>

another predicted patch idea. but i doubt 7 bit can represent TTL = 255
correctly.

> know a better reference than this RFC?

RFC2260 is informational rather than standard. BGP4 specification is
RFC4271 and you may be interested in the NEXT_HOP behavior of EBGP. TTL =
1, as i mentioned, is not a standard feature, but used in some
implementations (including Cisco IOS and Juniper JUNOS and the open-source
routing tool Quagga, to my best knowledge) in order to ensure the standard
feature that defaultly EBGP is established over an immediate link. as a
quick evidence of the implementation, in bgpd.c of quagga suite we may read
the piece of source code:

   peer->ttl = (peer_sort (peer) == BGP_PEER_IBGP ? 255 : 1);

it is saying, if the peer is IBGP, the TTL of IP header carrying it should
be set to 255; while if it is EBGP, TTL should be 1.

regards,
maoke

---

From: Maoke <[email-masked]>
Date: Tue, 27 Mar 2012 06:56:30 +0000

> require IPv4 dialogue between one link apart nodes.

btw, conceptually i don't suggest to call them "applications". actually BGP
is running over TCP but OSPF is over IP directly. they are of the
components of Internet infrastructure. the same understanding applies to
ICMP as well. - maoke

---

From: Rémi Després <[email-masked]>
Date: Tue, 27 Mar 2012 11:26:38 +0200

Le 2012-03-27 à 08:41, Maoke a écrit :

> dear Remi, 
> 
> sorry but i forgot the time difference this morning. thanks for the quick response!
> 
> if 4rd-u is limited to a very constrained scope, it is no problem. but people surely want to have a scalable solution. i listed issues of both inter-domain and intra-domain routing and i believe supporting some dynamic routing in the MAP domain is a natural requirement. 
>  
> any encapsulation is commonly, well understood to have such a feature without need of further explanation, without need of adding any elements in standard. we are now seldom discussing about the routing issue in the stateless solutions but we cannot block up the road to the real operation. 

Having a feature has never been expression of a requirement.

> well, my predicted response from you. :) please NOTE: MAP-T has never said it can "replace E".

In my recollection, double translation it has been proposed as a possibly unique standard but, OK, the MAP proposal is to have both MAP-T AND MAP-E as standards.

> this thread is about the importance of virtual link as an architectural building block that 4rd-u cannot offer.

See (*) below.

> MAP-T has none of business with this topic, because it is never considered virtual link. what i am arguing against, in this thread, is that "once operator has U it doesn't need either E or T". my point here is: 4rd-u cannot replace MAP-E, and accordingly the statement "4rd-u is a unified solution" is NOT qualified. 
> 
> it is not the topic of this thread if 4rd-u can replace MAP-T or not. i will go deep in that later, in another thread.

Then please leave me time to answer new discussion items you will introduce (may answers may be after the end of this week.)

> another predicted patch idea.

(*)
"Another" patch??
Just a solution to a feature you personally see add as a requirement.
It happens that I already thought about it, but didn't propose to include it because I had never saw a WG requirement for it.

> but i doubt 7 bit can represent TTL = 255 correctly. 

Did I suggest that?
(I hope you will someday have more respect for my design ability!)

> RFC2260 is informational rather than standard. BGP4 specification is RFC4271 and you may be interested in the NEXT_HOP behavior of EBGP. TTL = 1, as i mentioned, is not a standard feature, but used in some implementations (including Cisco IOS and Juniper JUNOS and the open-source routing tool Quagga, to my best knowledge) in order to ensure the standard feature that defaultly EBGP is established over an immediate link. as a quick evidence of the implementation, in bgpd.c of quagga suite we may read the piece of source code: 
> 
> it is saying, if the peer is IBGP, the TTL of IP header carrying it should be set to 255; while if it is EBGP, TTL should be 1. 

Not familiar enough with the subject to know whether these implementations cannot be configured so that they don't care.
I noted that RFC4271 doesn't have the word virtual link, and that RFC2328 only mentions "configured" virtual links (=> out of scope).  

If, despite this, you get WG support for a requirement of "1hop-only tunnels", the best answer is IMHO to include its support in 4rd-U.
This AFAIK will close this issue.

Thanks for this clarification,
RD

---

From: Maoke <[email-masked]>
Date: Tue, 27 Mar 2012 10:15:54 +0000

> it can "replace E".
> In my recollection, double translation it has been proposed as a possibly
> unique standard but, OK, the MAP proposal is to have both MAP-T AND MAP-E
> as standards.
>

we think MAP as a suite and -T and -E are to be used in different
circumstances where operators attach importance to different
considerations.

> MAP-T has none of business with this topic, because it is never considered
> virtual link. what i am arguing against, in this thread, is that "once
> operator has U it doesn't need either E or T". my point here is: 4rd-u
> cannot replace MAP-E, and accordingly the statement "4rd-u is a unified
> solution" is NOT qualified.
>
> Then please leave me time to answer new discussion items you will
> introduce (may answers may be after the end of this week.)
>

fully understood. but i won't stop in order to contribute my understandings
to the community stopping 4rd-u misleading the progress of standardization.

> It happens that I already thought about it, but didn't propose to include
> it because I had never saw a WG requirement for it.
>

well, really never a WG requirement. some dialogues have been there:

http://www.ietf.org/mail-archive/web/softwires/current/msg03106.html -- the
requirement
http://www.ietf.org/mail-archive/web/softwires/current/msg03109.html -- a
possible solution
http://www.ietf.org/mail-archive/web/softwires/current/msg03110.html -- the
concern on the possible solution and its little necessity

> (I hope you will someday have more respect for my design ability!)

"using the 7 remaining bits of IPv6 packet IDs for this" was not your
writing? i never doubt your design ability but i also hope we (you and me),
when designing anything, will someday have more respect for all other
designers and implementors, being a little conservative on what we will
generate to the Internet. very sincerely hope so!

this thread could be closed now. i have expressed my consideration. i also
have prepared some further clarification for OSPF and RIP but it looks you
are not interested in it. it is fine to me because operators and
implementors know very clearly about what i am concerning. just one comment
on BGP4 "doesn't have a word virtual link" --- all 6bone players may
remember that, at that time, we establish most of IPv6 BGP peers through
virtual links (tunnels), without the standard explicitly saying virtual
link.

conclusion has been cleared: 4rd-u cannot offer all that MAP-E (as
encapsulation supporting virtual link building block) can. 4rd-u is not a
tunnel at all.

so long,
- maoke

> Not familiar enough with the subject to know whether these implementations
> cannot be configured so that they don't care.
> I noted that RFC4271 doesn't have the word virtual link, and that RFC2328
> only mentions "configured" virtual links (=> out of scope).
>
> If, despite this, you get WG support for a requirement of "1hop-only
> tunnels", the best answer is IMHO to include its support in 4rd-U.

---

From: Rémi Després <[email-masked]>
Date: Tue, 27 Mar 2012 12:42:46 +0200

Le 2012-03-27 à 12:15, Maoke a écrit :

> we think MAP as a suite and -T and -E are to be used in different circumstances where operators attach importance to different considerations. 
>  
> 
> fully understood. but i won't stop in order to contribute my understandings to the community

Sure, and I appreciate your technical inputs.

> stopping 4rd-u misleading the progress of standardization. 

Different view on this.

> well, really never a WG requirement. some dialogues have been there:

I have to face that I didn't understand well enough the discussion thread below.
Thanks for the reminder. 
This is enough to convince me that, despite its not being recorded as a MAP requirement, TTL preservation is a real requirement for some ISPs.
Satoru-san wrote "what i would like to have is a consistent header processing for single/double translations and encapsulation", and I thought 4rd-U did achieve it.
It will when we add TTL transparency. 

> http://www.ietf.org/mail-archive/web/softwires/current/msg03106.html -- the requirement 
> http://www.ietf.org/mail-archive/web/softwires/current/msg03109.html -- a possible solution
> http://www.ietf.org/mail-archive/web/softwires/current/msg03110.html -- the concern on the possible solution and its little necessity
>  
> 
> 
> "using the 7 remaining bits of IPv6 packet IDs for this" was not your writing? i never doubt your design ability but i also hope we (you and me), when designing anything, will someday have more respect for all other designers and implementors, being a little conservative on what we will generate to the Internet. very sincerely hope so!

Implementors I have met (a number of them) don't find 4rd-U complicated.
For them, this is just a legend.

> this thread could be closed now. i have expressed my consideration. i also have prepared some further clarification for OSPF and RIP but it looks you are not interested in it.

Where did you see this?
My answer above testifies of my interest for having this solved in 4rd-U.

> it is fine to me because operators and implementors know very clearly about what i am concerning. just one comment on BGP4 "doesn't have a word virtual link" --- all 6bone players may remember that, at that time, we establish most of IPv6 BGP peers through virtual links (tunnels), without the standard explicitly saying virtual link. 
> 
> conclusion has been cleared: 4rd-u cannot offer all that MAP-E (as encapsulation supporting virtual link building block) can.

Different view, and not alone in that.

> 4rd-u is not a tunnel at all.

With TTL transparency added, I don't see what would be missing, even with all requirements you expressed.

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Tue, 27 Mar 2012 11:12:12 +0000

>> MAP-T has none of business with this topic, because it is never
>> considered virtual link. what i am arguing against, in this thread, is that
>> "once operator has U it doesn't need either E or T". my point here is:
>> 4rd-u cannot replace MAP-E, and accordingly the statement "4rd-u is a
>> unified solution" is NOT qualified.
>>
> This is enough to convince me that, despite its not being recorded as a
> MAP requirement, TTL preservation is a real requirement for some ISPs.
> Satoru-san wrote "what i would like to have is a consistent header
> processing for single/double translations and encapsulation", and I thought
> 4rd-U did achieve it.
> http://www.ietf.org/mail-archive/web/softwires/current/msg03110.html --
> the concern on the possible solution and its little necessity
>
>
>>
>>
> are not interested in it.
>
>
> Where did you see this?

it looks i misunderstood. i thought you were hurry to close this issue.

>
> it is fine to me because operators and implementors know very clearly
> about what i am concerning. just one comment on BGP4 "doesn't have a word
> virtual link" --- all 6bone players may remember that, at that time, we
> establish most of IPv6 BGP peers through virtual links (tunnels), without
> the standard explicitly saying virtual link.
>
> encapsulation supporting virtual link building block) can.
>
>

well, it is still uncertain how 4rd-u will do this. it is uncertain if the
new ad hoc complement doesn't introduce new problems. could we see it by
the end of IETF83?

thanks,
maoke

>> it is saying, if the peer is IBGP, the TTL of IP header carrying it
>> should be set to 255; while if it is EBGP, TTL should be 1.
>>
>>
>> Not familiar enough with the subject to know whether these
>> implementations cannot be configured so that they don't care.

---

From: Rémi Després <[email-masked]>
Date: Tue, 27 Mar 2012 14:02:09 +0200

Le 2012-03-27 à 13:12, Maoke a écrit :
> well, it is still uncertain how 4rd-u will do this. it is uncertain if the new ad hoc complement doesn't introduce new problems. could we see it by the end of IETF83? 

Sure.
basic ID: 
- At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop count, and bits 1-7 in the remaining space of the IPv6 packet ID. Put 127 in bits 1-7 of the hop count.
- A exit, take bit 0 from the hop count, and bits 1-7 from the packet ID. 

The only constraint it introduces is that the longest IPv6 path within the domain must not exceed 127 (something that AFAIK shouldn't be a problem)
OK?

RD

---

From: Maoke <[email-masked]>
Date: Wed, 28 Mar 2012 03:21:24 +0000

> - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop count,
> and bits 1-7 in the remaining space of the IPv6 packet ID. Put 127 in bits
> 1-7 of the hop count.
>
>
>
> The only constraint it introduces is that the longest IPv6 path within the
> domain must not exceed 127 (something that AFAIK shouldn't be a problem)
>
>

"AFAYK" cannot be considered as a common understanding. well, it seems
creative though really causes several new concerns:

1. nobody can think the leftmost bit of Hop Limit in IPv6 header is marked
as "unused" or "unspecified" (actually it is often used). you'd better to
update RFC2460 first.
2. not sure that IPv6 path within a domain larger than 127 hops is a corner
case that is more-corner than the corner of DF=MF=1. in fact, this is to
change the definition of routing loop criterion in a IPv6 network.
3. even domain diameter less than 127 is always true, MAP-E's generic
encapsulation module can works for both the MAP and also the stateful
tunneling across multiple domains unless the hop count exceeds what IPv6
protocol allows; while 4rd-u CE's header mapping module cannot be reused
for stateful tunneling over multiple IPv6 domains (also because the
processings are different). (you may say this is out of scope but i do hope
you respect other people's scope of concern. thanks in advance!)

(and it is really tough for implementators. maybe not your care and you may
state it is simple. therefore i parenthesize this phrase.)

on the other hand, besides the above concerns, there are still some
technical flaws of this solution itself.

*1. consider a case where 2 CEs, 1 hop apart in IPv6 domain, establish EBGP
session over IPv6 with their 4rd addresses as the loopback addresses and
ttl-security is set to, e.g., 254, in order to protect the peer from
receiving attack messages sending by a remote third party with snoofing.
the mechanism of having IPv4 TTL's bit 0 in IPv6 Hop Limit may offer a
chance for the IPv4 node behind the CE, breaking the protection of the
ttl-security, because the TCP carrying BGP is directly exposed as the
payload of the generated IPv6 packet like translation but the Hop Limit is
not correctly decreased.

*2. when routing loop happens in the IPv6 domain, unfortunately, the Time
Exceeded (hop limit exceeded) ICMPv6 message will be translated to Time
Exceeded ICMPv4 error (according to 4rd-05, R-16), rather than a
link-problem as is expected as a report on the problem of the 1-hop tunnel
link. this must be confusing.

best,
maoke

>
> OK?
>
> RD
>
>
> thanks,
> maoke
>
>
>>
>> Regards,
>> RD
>>
>>
>>
>>
>> so long,
>> - maoke
>>
>>
>>
>>>
>>>
>>>  d) I didn't see any reference to TTL = 1 in the EBGP of RFC2260. Do
>>>> you know a better reference than this RFC?
>>>>
>>>
>>> I noted that RFC4271 doesn't have the word virtual link, and
>>> that RFC2328 only mentions "configured" virtual links (=> out of scope).
>>>

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 28 Mar 2012 06:10:54 +0200

FYI, section 5 of RFC5082 (http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique that TTL is used to help tunnel packets security. Anyway, 

> - A exit, take bit 0 from the hop count, and bits 1-7 from the packet ID. 

Too much. Don't change deeply well understand/deployed semantics, PLEASE.

> The only constraint it introduces is that the longest IPv6 path within the domain must not exceed 127 (something that AFAIK shouldn't be a problem)

NO.

cheers,
--satoru

---

From: Maoke <[email-masked]>
Date: Wed, 28 Mar 2012 07:59:05 +0000

2012/3/28 Maoke <[email-masked]>

>
> *1. consider a case where 2 CEs, 1 hop apart in IPv6 domain, establish
> EBGP session over IPv6 with their 4rd addresses as the loopback addresses
> and ttl-security is set to, e.g., 254, in order to protect the peer from

snoofing => spoofing (typo, sorry).

---

From: Rémi Després <[email-masked]>
Date: Wed, 28 Mar 2012 10:26:40 +0200

Le 2012-03-28 à 05:21, Maoke a écrit :

> "AFAYK" cannot be considered as a common understanding. well, it seems creative though really causes several new concerns: 
> 
> 1. nobody can think the leftmost bit of Hop Limit in IPv6 header is marked as "unused" or "unspecified" (actually it is often used). you'd better to update RFC2460 first. 

No need for any update AFAIK.

> 2. not sure that IPv6 path within a domain larger than 127 hops is a corner case that is more-corner than the corner of DF=MF=1. in fact,

Difference:
- Domain longest path is a local matter that can be ensured by ISPs.
- DF=MF=1 is a service restriction that affects some users.

> this is to change the definition of routing loop criterion in a IPv6 network. 

???

> 3. even domain diameter less than 127 is always true, MAP-E's generic encapsulation module can works for both the MAP and also the stateful tunneling across multiple domains unless the hop count exceeds what IPv6 protocol allows; while

> 4rd-u CE's header mapping module cannot be reused for stateful tunneling over multiple IPv6 domains

Sorry I don't see the scenario you have in mind.

> (also because the processings are different).

> (you may say this is out of scope

It sure seems to me out of scope.

> but i do hope you respect other people's scope of concern. thanks in advance!) 

I do respect that, but need to understand what is meant.
Besides, there are enough in-scope issues being discussed to please defer off-sope issues.

> (and it is really tough for implementators. maybe not your care and you may state it is simple. therefore i parenthesize this phrase.)

I do care about implementation, as other co-authors do.
Please don't suggest we don't.

> on the other hand, besides the above concerns, there are still some technical flaws of this solution itself. 
> 
> *1. consider a case where 2 CEs, 1 hop apart in IPv6 domain, establish EBGP session over IPv6 with their 4rd addresses as the loopback addresses and ttl-security is set to, e.g., 254, in order to protect the peer from receiving attack messages sending by a remote third party with snoofing. the mechanism of having IPv4 TTL's bit 0 in IPv6 Hop Limit may offer a chance for the IPv4 node behind the CE, breaking the protection of the ttl-security, because the TCP carrying BGP is directly exposed as the payload of the generated IPv6 packet like translation but the Hop Limit is not correctly decreased. 

Not understood.
I have difficulty to see why a -E tunnel would be different from a -U tunnel since both will keep TTL transparency, independently of TTL values. 

> *2. when routing loop happens in the IPv6 domain, unfortunately, the Time Exceeded (hop limit exceeded) ICMPv6 message will be translated to Time Exceeded ICMPv4 error (according to 4rd-05, R-16), rather than a link-problem as is expected as a report on the problem of the 1-hop tunnel link. this must be confusing. 

-E seems to have the problem because this is how RFC6145 translates ICMPv6 to ICMPv4.

Cheers,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 28 Mar 2012 11:05:49 +0200

> Too much. Don't change deeply well understand/deployed semantics, PLEASE.

Semantics isn't changed for any existing function.
CEs and BRs (the only ones to be concerned) use unused bits to convey some IPv4 bits that need to be conveyed for e2e transparency.
No implementation or operational problem can result.

If I missed a practical problem you have identified, sharing this information would of course be useful.

Thanks,
RD

---

From: Maoke <[email-masked]>
Date: Wed, 28 Mar 2012 09:25:31 +0000

2012/3/28 Rémi Després <[email-masked]>

> No need for any update AFAIK.

significant semantics change without update, without definition, but
requires peer and operators awareness. -- AFAIK, it is not acceptable.

>
>
> 2. not sure that IPv6 path within a domain larger than 127 hops is a
> corner case that is more-corner than the corner of DF=MF=1. in fact,
>
>
> Difference:

see also below (*)

> this is to change the definition of routing loop criterion in a IPv6

for IPv4 packets with TTL=64, it would be reported fail after being
forwarded in the IPv6 network 127 times; for IPv4 packets with TTL=128, it
would be reported fail after 255 times of forwarding in IPv6. criterion is
uncertain.

(*)
considering that temporarily routing loop happens when distance vector or
link state changes, the limitation of 127 hops makes the diameter of the
actual workable IPv6 network less than 127. operators can ensure the stable
state path length but cannot ensure the case in state-transition.
unfortunately, you cannot force IPv4 applictions always initializing TTL
larger than 127 in order to gain the 255 HopLimit in IPv6.

-E works fine with the commonly understood behavior and commonly, well
understood limitations, without bias to any value of IPv4 TTL.

> protocol allows; while

sorry but 4rd-u CE needs two modules working for 4rd-u header mapping and
stateful tunnel/encapsulation, respectively.

> Besides, there are enough in-scope issues being discussed to please defer

your scope is different from ours.

>
> (and it is really tough for implementators. maybe not your care and you
> may state it is simple. therefore i parenthesize this phrase.)
>
>

then please deeply consider what Satoru suggested: don't change the deeply
understood semantics so much. and please consider the annoyance of copying
this bit here while those bits there even for a single octet. it is surely
doable and not extremely complicated though.

> I have difficulty to see why a -E tunnel would be different from a -U
> tunnel since both will keep TTL transparency, independently of TTL values.
>

please carefully read the example. the problem here has changed. it is
about the ttl-security of IPv6 routing rather than the TTL transparency of
the tunneled IPv4 (which you have patched with the not-beautiful but anyway
a solution). i show this example here in order to point out HopLimit > 127
is in use even if the diameter of a domain less than 127. Satoru also gave
a link to a reference.

-E has not the similar problem because the encapsulation won't expose an
BGP message to the IPv6 peer. -T has not the problem either because the
HopLimit is copied from IPv4 TTL and the ttl-security works in checking
that HopLimit.

> -E seems to have the problem because this is how RFC6145 translates ICMPv6

misunderstanding. -E doesn't have the problem because RFC6145 translation
for ICMPv6-to-ICMPv4 is never utilized in -E. it would be helpful if you
may take some time to get to understand the ICMPv6/iCMPv4 translation
semantics. they are different for -E and -T.

thanks,
maoke

---

From: Maoke <[email-masked]>
Date: Wed, 28 Mar 2012 09:30:55 +0000

> > FYI, section 5 of RFC5082 (
> http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique
> that TTL is used to help tunnel packets security. Anyway,
> >
> >>> well, it is still uncertain how 4rd-u will do this. it is uncertain if
> the new ad hoc complement doesn't introduce new problems. could we see it
> by the end of IETF83?
> >>
> >> Sure.
> >> basic ID:
> CEs and BRs (the only ones to be concerned) use unused bits to convey some
> IPv4 bits that need to be conveyed for e2e transparency.
>

unfortunately the first bit of Hop Limit is NOT "unused" at all. please
also pay attention the reference that others suggested. - maoke

> >> The only constraint it introduces is that the longest IPv6 path within
> the domain must not exceed 127 (something that AFAIK shouldn't be a problem)
> >> OK?
> >
> > NO.
> >
> > cheers,
> > --satoru
>
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 28 Mar 2012 12:03:39 +0200

Le 2012-03-28 à 11:30, Maoke a écrit :

> unfortunately the first bit of Hop Limit is NOT "unused" at all. please also pay attention the reference that others suggested.

Would you be kind enough to give again the reference of the document you are referring to?
I will look at it.
Thanks.

RD

---

From: Maoke <[email-masked]>
Date: Wed, 28 Mar 2012 10:39:15 +0000

>> >>> well, it is still uncertain how 4rd-u will do this. it is uncertain
>> if the new ad hoc complement doesn't introduce new problems. could we see
>> it by the end of IETF83?
>> >>
>> >> Sure.
>> >> basic ID:
>> >> - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop
>> count, and bits 1-7 in the remaining space of the IPv6 packet ID. Put 127
>> in bits 1-7 of the hop count.
>> CEs and BRs (the only ones to be concerned) use unused bits to convey
>> some IPv4 bits that need to be conveyed for e2e transparency.
>>
>
> also pay attention the reference that others suggested.
>
>

thank you, Remi, and here you are.

what Satoru pointed out is:
> FYI, section 5 of RFC5082 (http://tools.ietf.org/html/rfc5082#section-5.2)
generalize a technique that TTL is used to help tunnel packets security.

and i'd like also suggest Cisco IOS and Juniper JUNOS documents about
security issues regarding ttl or hop limit. sorry but it is hard to specify
a very specific page because we need to pay attention to understand the
whole problem. but it is not hard to google them out. (RFC2080 also covers
the similar issue regarding RIPng, though multicast over the hop is
involved, which might be not in the current scope of MAP while might be in
the near future).

thanks again for your attention.

- maoke

---

From: Rémi Després <[email-masked]>
Date: Wed, 28 Mar 2012 12:46:44 +0200

Le 2012-03-28 à 11:25, Maoke a écrit :

> significant semantics change without update, without definition, but requires peer and operators awareness. -- AFAIK, it is not acceptable. 

Different understanding.
If you identify an operational issue, thanks for sharing it.)

> for IPv4 packets with TTL=64, it would be reported fail after being forwarded in the IPv6 network 127 times; for IPv4 packets with TTL=128, it would be reported fail after 255 times of forwarding in IPv6. criterion is uncertain.  
> 
> (*)
> considering that temporarily routing loop happens when distance vector or link state changes, the limitation of 127 hops makes the diameter of the actual workable IPv6 network less than 127. operators can ensure the stable state path length but cannot ensure the case in state-transition. unfortunately, you cannot force IPv4 applictions always initializing TTL larger than 127 in order to gain the 255 HopLimit in IPv6. 
> 
> -E works fine with the commonly understood behavior and commonly, well understood limitations, without bias to any value of IPv4 TTL. 
>  
> 
> sorry but 4rd-u CE needs two modules working for 4rd-u header mapping and stateful tunnel/encapsulation, respectively. 

Sorry, I don't follow what is meant.
> your scope is different from ours. 

This collective "ours" is unclear to me.
- Is there an identified group you are representing? 
- Then which one?
In any case this off-scope issue remains unclear to me.

> then please deeply consider what Satoru suggested: don't change the deeply understood semantics so much. and please consider the annoyance of copying this bit here while those bits there even for a single octet. it is surely doable and not extremely complicated though.
>  
> please carefully read the example. the problem here has changed. it is about the ttl-security of IPv6 routing rather than the TTL transparency of the tunneled IPv4 (which you have patched with the not-beautiful but anyway a solution). i show this example here in order to point out HopLimit > 127 is in use even if the diameter of a domain less than 127. Satoru also gave a link to a reference. 
> 
> -E has not the similar problem because the encapsulation won't expose an BGP message to the IPv6 peer. -T has not the problem either because the HopLimit is copied from IPv4 TTL and the ttl-security works in checking that HopLimit. 

I am not an expert of this application, but fail to understand while there would be any problem since:
- with its added TTL preservation, U is completely transparent to TTLs
- unless I am mistaken, the protocol you refer to is between two IPv4 modules.

> misunderstanding. -E doesn't have the problem because RFC6145 translation for ICMPv6-to-ICMPv4 is never utilized in -E.

What happens then if a BR to CE packet, for example, is discarded by an in-domain IPv6 router?
- A BR will receive an ICMPv6 error message, right?
- Will it be just ignored, or translated to ICMPv4?
 
> it would be helpful if you may take some time to get to understand the ICMPv6/iCMPv4 translation semantics. they are different for -E and -T. 

Once more one of these statements I would have preferred not to hear from you.

RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 28 Mar 2012 14:10:52 +0200

On the subject of TTL semantics between adjacent nodes, here is what I understand (so far):
- Some protocols above IP, only applicable between adjacent nodes, can be better protected if TTLs are set to 255 by sources.
- This is important if there is no ingress filtering (a situation that should be avoided in 4rd domains anyway, but let's accept it).

Now, with the now specified TTL-presevation of 4rd-U, the IPv6 hop count derived from an IPv4 TTL=255 is also 255, which is the desirable value.

If I missed something, please don't get crossed, your additional explanations will be welcome.

Regards,
RD

Le 2012-03-28 à 12:39, Maoke a écrit :

> > FYI, section 5 of RFC5082 (http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique that TTL is used to help tunnel packets security.
> 
> and i'd like also suggest Cisco IOS and Juniper JUNOS documents about security issues regarding ttl or hop limit. sorry but it is hard to specify a very specific page because we need to pay attention to understand the whole problem. but it is not hard to google them out. (RFC2080 also covers the similar issue regarding RIPng, though multicast over the hop is involved, which might be not in the current scope of MAP while might be in the near future). 
>

---

From: Maoke <[email-masked]>
Date: Thu, 29 Mar 2012 09:33:15 +0000

dear Remi,

> - Some protocols above IP, only applicable between adjacent nodes, can be
> better protected if TTLs are set to 255 by sources.
> - This is important if there is no ingress filtering (a situation that
> should be avoided in 4rd domains anyway, but let's accept it).
>
> Now, with the now specified TTL-presevation of 4rd-U, the IPv6 hop count
> derived from an IPv4 TTL=255 is also 255, which is the desirable value.
>

with your newly proposed solution, yes, IPv4 TTL is fine. but on the other
hand, the IPv6 also needs TTL(HopLimit)=255 to protect something. we have
to concern if 4rd-u possibly introduces some new measures for the attackers
breaking such kind of protection mechanism, as putting the first bit of
IPv4 TTL into IPv6 HopLimit CHANGES the semantics of IPv6's HopLimit!

regards,
maoke