Subject: [Softwires] comments on draft-ietf-softwire-ipv6-6rd-03

From: WashamFan <[email-masked]>
Date: Sun, 10 Jan 2010 19:45:39 +0800

Hi,

Techincal comments:

1. 6rd BR definition in section 3 says:

6rd Border Relay (BR) A 6rd-enabled router managed by the service
                         provider at the edge of a 6rd domain.  The 6rd
                         BR router has at least one of each of the
                         following: an IPv4-enabled interface, a 6rd
                         virtual interface acting as an endpoint for the
                         6rd IPv6 in IPv4 tunnel, and an IPv6 interface
                                                                 ^^^^^^^^^^^
                         connected to the native IPv6 network.  A 6rd BR
                         ^^^^^^^^^^^^^^^^^^^^^^^^
                         may also be referred to simply as a "BR" within
                         the context of 6rd.

6rd BRs might not be deployed in IPv4/IPv6 border or 6rd BRs
might use virtual interface (v.s. physical interface) to connect to 
a IPv6 overlay (v.s. native IPv6).

The same situation applies to 6rd CEs, e.g., a 6rd CE might be
an ISATAP router.

2. section 4 talks about 6rd delegated prefix delegation rather
than 6rd prefix delegation. Should the title be changed?

3. section 6 says 6rd addresses should be treated as native
addresses and no changes are needed for address selection.

6rd is a native-equivalent IPv6, but not native IPv6 after all.
When a customer is connected to a 6rd IPv6 and native IPv6
at the same time, (s)he might only want to use 6rd address
when (s)he communicates with hosts within the 6rd domain.

4. the 6rdPrefixLen semantics in section 7.1.1 says:

6rdPrefixLen              The IPv6 Prefix length of the SP's 6rd IPv6
                             prefix in number of bits.  For the purpose
                             of bounds checking by DHCP option
                             processing, the sum of (32 - IPv4PrefixLen)
                             + 6rdPrefixLen MUST be less than or equal 
                                                  ^^^^^^^^^^^^^^^^^^
                             to 128.  The 6rd implementation may further
                             ^^^^
                             limit the sum of these lengths to 64.

But the last sentences in para2, sec4 says
   
   To allow for stateless address auto-configuration on
   the CE LAN Side, a 6rd delegated prefix MUST be /64 or shorter.

the sum of (32-IPv4PrefixLen)+6rdPrefixLen = size of the
6rd delegated prefix. Is it an inconsistency?
 
5. at the end of the section 7.2, the RIB appears as:

   ::/0 -> 2001:ABC0:0000:0100::   (default route)
   2001:ABC0::/32 -> 6rd-virtual-interface0 (direct connect to 6rd)
   2001:ABC0:6464:0100::/56 -> Null0 (delegated prefix sink route)
   2001:ABC0:6464:0100::/64 -> Ethernet0 (LAN interface)

The routes are confusing. The first route indicates the next
hop whileas the rest routes indicate the coresponding interface.
Actually, the first route should have indicated 6rd-virtual-interface0
but with the specific next hop 2001:ABC0:0000:0100::

6. In section 8, you give one recommended method for NUD
between CEs and BRs, so what is recommended for NUD
between CEs and BRs? 

7. It is still hard for me to get to looping issues described in 
section 12, it would help if an example was there.

8. compared to 6to4 spec (rfc3056), this document does not
mention the routing exchange between CEs and BRs, especially
when anycast is not used for BR discovery. Is this the original
intention?

editorial comments:

9. the first sencence in para4, sec1:

   A 6rd domain consists of 6rd Customer Edge (CE) routers and one or
   more 6rd BRs. 
           ^^^^^
I prefer "6rd Border Relay (BR) routers" instead.

10. CE IPv4 address definition in sec3:

CE IPv4 address       The IPv4 address given to the CE as part of
                         normal IPv4 Internet access (i.e., configured
                         via DHCP, PPP, or otherwise).  This address may
                         be global or private [RFC1918] within the 6rd
                         domain.  This address is used by a 6rd CE to
                         create the 6rd delegated prefix as well as to
                         send and receive IPv4 encapsulated IPv6
                                                  ^^^^^^^^^^^^^^
                         packets.

Should it be IPv6 encapsulated IPv4?

11. 1st sentence in sec4:

   The 6rd delegated prefix for use at a customer site is created by
   combining the 6rd prefix and some or all of the CE IPv4 Address.
                                                                                  ^^^^^^
addresses.

12. the para2, sec4:

   In 6to4, a similar operation is performed by incorporating an entire
   IPv4 address at a fixed location within a well-known /16 IPv6 prefix.
                                                ^^^^ following
   In 6rd, the IPv6 prefix as well as the position and number of bits of
   the IPv4 address incorporated varies from one 6rd domain to the next.
   6rd allows the SP to adjust the size of the 6rd prefix, bits used by
                                                                              ^how many
   the 6rd mechanism, and how many bits are left to be delegated to
   customer sites.  To allow for stateless address auto-configuration on
   the CE LAN Side, a 6rd delegated prefix MUST be /64 or shorter.

13. IID is not in right propositional to the address length in figure 1.

14. last para, sec5:

  The 6rd CE and BR SHOULD support the IPv6 Subnet-Router anycast
   address [RFC4291] for its own 6rd delegated prefix.  This allows, for
   example, IPv6 ping messages to be sent to the 6rd Virtual Interface
   itself for additional troubleshooting of the internal operation of
   6rd at a given CE or BR, over and above an IPv4 ping to the
                                      ^^^^^^^^^^^^^^^^^^^ ( I don't get it)
   associated CE or BR IPv4 address.  In the case of the BR, the IPv4
   address used to calculate the 6rd delegated prefix is the configured
   BR IPv4 Address.

15. para2, sec9:

   IPv6 packets from a CE are encapsulated in IPv4 packets when they
   leave the site via its CE WAN Side interface.  The CE IPv4 address
                                                                   ^^^ A
   MUST be configured to send and receive packets on this interface.

Thanks,
washam

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jan 2010 08:05:12 +1300

On 2010-01-11 00:45, WashamFan wrote:
...
> when (s)he communicates with hosts within the 6rd domain.

Well, consider what is said about the equivalent issue for
6to4, in RFC 3056:

   If both hosts have a 6to4 address and a native IPv6 address, then
   either the 6to4 address should be used for both, or the native IPv6
   address should be used for both.  The choice should be configurable.
   The default configuration should be native IPv6 for both.

In other words, if the RFC 3484 default doesn't do what the customer
wants, an extra policy would be needed for the specific prefixes
concerned. It seems to me that the draft is correct: treat the 6rd
prefix exactly as if it was native.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 11 Jan 2010 12:25:23 +0100

Washam,

thanks for all your comments!

>                         6rd IPv6 in IPv4 tunnel, and an IPv6 interface

indeed. but I don't think we need to say anything about that in the draft.

> than 6rd prefix delegation. Should the title be changed?

the mechanism is called "prefix delegation", while the resulting prefix is called a "delegated prefix". hopefully that doesn't create too much confusion.

> when (s)he communicates with hosts within the 6rd domain.

I concur with Brian here.

>                             + 6rdPrefixLen MUST be less than or equal 

just maintaining the ambiguity we have with IPv6 today. ;-)
 should the 64 bit boundary be enforced in the DHCP option bounds checking?
I see no technical reason why the DHCP option shouldn't allow for any prefix length. at the same time we want to point out that unless it is at least a /64 then SLAAC will not work.

> but with the specific next hop 2001:ABC0:0000:0100::

agree, I've added that to the RIB example:
   ::/0 -> 6rd-virtual-interface0 via 2001:ABC0:0000:0100::   (default route)
   2001:ABC0::/32 -> 6rd-virtual-interface0 (direct connect to 6rd)
   2001:ABC0:6464:0100::/56 -> Null0 (delegated prefix sink route)
   2001:ABC0:6464:0100::/64 -> Ethernet0 (LAN interface)

> between CEs and BRs, so what is recommended for NUD

I'm not quite sure what you mean here?

> section 12, it would help if an example was there.

yes, me too. ;-)
check out:
http://www.townsley.net/ietf76/townsley-ietf76-softwires-6rd-update.pdf

and Nakibly and Arov's 
[USENIX09
]
              Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6
              Tunnels, USENIX WOOT", August 2009.

I'll add an informative reference to this paper.

> when anycast is not used for BR discovery. Is this the original

yes. we are considering the same deployment scenario as e.g 
draft-ietf-v6ops-ipv6-cpe-router and there is no dynamic routing between a CPE and a service provider's edge.

> I prefer "6rd Border Relay (BR) routers" instead.

agree, fixed.

>                         send and receive IPv4 encapsulated IPv6

absolutely, fixed.

>   combining the 6rd prefix and some or all of the CE IPv4 Address.

actually it is singular. changed "some" to "part of". this is the case where part of the IPv4 prefix can be pre-configured on all 6rd nodes and therefore you don't need to encode the complete 32 bit IPv4 address in the IPv6 address.

>   IPv4 address at a fixed location within a well-known /16 IPv6 prefix.

fixed.

>   6rd allows the SP to adjust the size of the 6rd prefix, bits used by

fixed.

> 13. IID is not in right propositional to the address length in figure 1.

fixed.

>   address used to calculate the 6rd delegated prefix is the configured

we just tried to say that with a well known IPv6 address to ping (subnet router anycast) then that can be used for troubleshooting. in addition to using the IPv4 address. happy to edit if you have a suggestion of better text.

>   MUST be configured to send and receive packets on this interface.

"A"?

thanks again for very thorough comments!

cheers,
Ole

---

From: Mark Townsley <[email-masked]>
Date: Mon, 11 Jan 2010 13:15:42 +0100

> thanks for all your comments!
Yes, Thanks.

Ole, just a couple of comments on the proposed minor bug fixes...
>> Should it be IPv6 encapsulated IPv4?
I think only a hyphen is missing for clarity. The sentence is speaking 
about "IPv4-encapsulated IPv6 packets."

Or, "IPv6 packets encapsulated in IPv4 by 6rd" if that's more clear.
> actually it is singular. changed "some" to "part of". this is the case where part of the IPv4 prefix can be pre-configured on all 6rd nodes and therefore you don't need to encode the complete 32 bi…
"part of" alone might not allow for "all" in my reading of the sentence. 
If "some or all" is confusing, please change to something like "all or 
part of" rather than just "part of".

> we just tried to say that with a well known IPv6 address to ping (subnet router anycast) then that can be used for troubleshooting. in addition to using the IPv4 address. happy to edit if you have…
Washam - Point is that an IPv4 ping, and an IPv6 ping encapsulated in 
the same IPv4 address by 6rd both test the same reachability in terms of 
the CE to BR or CE to CE communication path, etc. Using IPv6 goes a bit 
further than that by ensuring that the 6rd mechanism itself is working 
correctly.

- Mark

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Jan 2010 18:39:40 +0100

> concerned.

> It seems to me that the draft is correct: treat the 6rd

+1 
The draft is right.

RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Jan 2010 23:11:14 +0100

> I see no technical reason why the DHCP option shouldn't allow for any prefix length. at the same time we want to point out that unless it is at least a /64 then SLAAC will not work.

+1
The way it is expressed if fine.

RD

---

From: WashamFan <[email-masked]>
Date: Tue, 12 Jan 2010 11:04:35 +0800

Hi,

>  I'm not quite sure what you mean here?

Sorry for ambiguity. I was asking, can the method described in sec8 for
reachability detection between a CE and a BR apply to reachability detection 
between CEs. But after the second thought, I realised it contradicts
receiving rules described in sec9.2 for CEs if it apply to the reachability
detection between CEs. Sorry for bother ;)

>  I'll add an informative reference to this paper.

Thanks for the information. Unfortunately, the most important pdf pages
are blank because of "token type not recognized" and the reference
you are refering to seems unavailable to me (via google). 
Could you point out alternatives to help understand the looping attack?
Thanks.

>  >   MUST be configured to send and receive packets on this interface.

Should the "The" the second sentence starts with be "A" instead?

washam

---

From: Mark Townsley <[email-masked]>
Date: Tue, 12 Jan 2010 05:21:37 +0100

> are blank because of "token type not recognized" and the reference
Sorry about that. I just tried again and had no problem with PDF, if 
anyone else has this problem I'd be interested to know how to resolve it.

In any case, I've uploaded a couple of other formats (the second is a 
directory of .jpg files of each slide). Hope that helps

http://www.townsley.net/ietf76/townsley-ietf76-softwires-6rd-update.ppsx

http://www.townsley.net/ietf76/townsley-ietf76-softwires-6rd-update/

> you are refering to seems unavailable to me (via google).
This came up as the top hit for me with Google:

http://www.usenix.org/event/woot09/tech/full_papers/nakibly.pdf

- Mark
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: WashamFan <[email-masked]>
Date: Tue, 12 Jan 2010 14:57:21 +0800

Hi,

>  http://www.usenix.org/event/woot09/tech/full_papers/nakibly.pdf

Thanks. Now I think I get this issue clearly. But after re-read the relevant
text, I found a tiny confusion.

para3, sec12 says:

   A malicious user that is aware of a 6rd domain and the BR IPv4
   address could use this information to construct a packet that would
   cause a Border Relay Router to reflect tunneled packets outside of
   the domain that it is serving.  If the attacker constructs the packet
   accordingly, and can inject a packet with an IPv6 source address that
   looks as if it originates from within the 6rd domain of the second
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   border relay, forwarding loops between 6rd domains may be created,
   ^^^^^^^
   allowing the malicious user to launch a packet amplification attack
   between 6rd domains.

"the second border relay" here is confusing, I firstly got an impression that 
"it originates from the second BR within the same 6rd domain", 
So I suggest the text below

   A malicious user that is aware of a 6rd domain and the BR IPv4
   address could use this information to construct a packet that would
   cause a Border Relay Router to reflect tunneled packets outside of
   the domain that it is serving.  If the attacker constructs the packet
   accordingly, and can inject a packet with an IPv6 source address that
   looks as if it originates from within another 6rd domain, 
                ----------------------------------------------
   forwarding loops between 6rd domains may be created,
   allowing the malicious user to launch a packet amplification attack
   between 6rd domains.

washam

---

From: Mark Townsley <[email-masked]>
Date: Tue, 12 Jan 2010 08:14:32 +0100

I agree that your suggested text is more clear. Thanks again for the 
continued careful review.

- Mark