Subject: [Softwires] Please review 6rd

From: Mark Townsley <[email-masked]>
Date: Wed, 06 Jan 2010 20:59:13 +0100

Softwires,

Happy New Year all. I hope none of you are fixing Jan 1, 2010 bugs in 
your code these days ;-)

You may have seen a -02 followed quickly by a -03 
draft-ietf-softwire-ipv6-6rd. The reason for the quick rev was a math 
bug in one of the recommended bounds checks that we let get into -02. 
Thanks to Jerry Huang for bringing it to our attention. We thought it 
was important enough to be fixed right away, as we hope this it the 
version that we can take to last call, and understand that 
implementations may be in the works as well.

-03 includes quite a bit of text cleanup, and addresses comments 
received in Hiroshima, on-list, and some side comments that came in as well.

Chairs,

Apologies for not meeting the "one week after Hiroshima" or even our own 
self-imposed "before the Holidays" deadline. On the bright side, we made 
it in before the pre-Anaheim deadline rush! Everyone should have plenty 
of cycles to review for us right now. So, unless there is any major 
objection, I'd like to request a Last Call.

Many Thanks,

- Mark

---

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

Mark,

I may have a few more minor points to review with you when we meet as planned, but the following are for immediate consideration by all.

In 7.2, after
"However, the 6rd IPv4 relay anycast addresses must be advertised in the service provider's IGP"
I suggest to add, 
" and, to avoid undesirable traffic in 6rd border relays (BRs), should not be advertised outside the 6rd domain (see also security considerations in [section 12])"

In 9.2, after
"Additionally, a CE MUST allow packets sourced by the configured BR IPv4 Address",
I suggest to add, for anti spoofing,
", provided their IPv6 source address doesn't start with the 6rd prefix".

I will also try to propose something on routing-loop avoidance.

Cheers,

RD

---

From: Mark Townsley <[email-masked]>
Date: Mon, 11 Jan 2010 21:02:09 +0100

> " and, to avoid undesirable traffic in 6rd border relays (BRs), should not be advertised outside the 6rd domain (see also security considerations in [section 12])"
The major point is that the BR IPv4 address be unreachable outside the 
6rd domain, and this is one way to help restrict that scope. In that 
vein, I think it would be OK to recommend this (but its of course not 
the only tool at he operators disposal).
> ", provided their IPv6 source address doesn't start with the 6rd prefix".
We've had operators interested in at least having the option to send 
traffic through the BR even for CE sourced traffic from within the same 
domain. Also, it is useful in some possible transition-to-native 
scenarios to allow this. So, unless you have an identifiable security 
concern that this helps to mitigate, I'd rather not add this kind of 
restriction on the CE (and, it's an extra check, adding to complexity).
> I will also try to propose something on routing-loop avoidance.
Thanks. Note that I'd rather avoid a detailed discussion on all the 
looping possibilities (that's fine for the research paper Ole cited, or 
the slides I put together in Hiroshima, or an Internet Draft on 6rd 
Operations that I still hope to see some Operators produce, etc.). For 
this document, I think it is better to keep the text limited strictly to 
the implementation specification necessary to keep the possibilities of 
spoofing and looping limited so 6rd cannot be exploited to invoke a 
serious attack. I think we've captured that already, but please let me 
know if you think we are missing some important normative language.

- Mark

---

From: WashamFan <[email-masked]>
Date: Tue, 12 Jan 2010 10:43:33 +0800

>  restriction on the CE (and, it's an extra check, adding to complexity).

Please note that in section 8, the recommended method for reachability
detection between CEs and BRs allows for CE sourced traffic "U-turn"
BRs.

washam

---

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

> detection between CEs and BRs allows for CE sourced traffic "U-turn"
Yes, that too! Thanks.

- Mark

---

From: Rémi Després <[email-masked]>
Date: Wed, 13 Jan 2010 10:41:32 +0100

Mark,

As we discussed, but for all to be aware, the reference to RFC 5569 will now be appropriate to replace that to draft-despres-6rd [I-D.despres-6rd].

As The RFC editor wrote on Dec 29, 2009, "The updates unblock the Independent stream, and we hope to publish all of the Independent documents stuck in AUTH48 in the first couple of
weeks on 2010".

Regards,
RD

---

From: Mark Townsley <[email-masked]>
Date: Wed, 13 Jan 2010 10:57:34 +0100

> As we discussed, but for all to be aware, the reference to RFC 5569 will now be appropriate to replace that to draft-despres-6rd [I-D.despres-6rd].
Will do, and I am very happy to see that the Independent Stream and your 
document in particular seems to finally be unblocked.

- Mark

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 14 Jan 2010 18:04:09 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代
表
> Mark Townsley
> 发送时间: 2010年1月12日 4:02
> 收件人: Rémi Després
> 抄送: [email-masked]
> 主题: Re: [Softwires] Please review 6rd
> 
> > I may have a few more minor points to review with you when we meet as
planned,
> but the following are for immediate consideration by all.
> >
> >
> > In 7.2, after
> > " and, to avoid undesirable traffic in 6rd border relays (BRs), should
not
> be advertised outside the 6rd domain (see also security considerations in
> [section 12])"
> >

There was a related discussion about how to avoid routing loops between
multiple ISATAP routers (See
http://www.ietf.org/mail-archive/web/softwires/current/msg00857.html).
Somebody argued that it is not practical for the ISATAP routers to use IPv4
address which is unreachable outside the ISATAP domain in some cases. Hence
I wonder whether the argument is also suitable for the 6rd scenario.

By the way, would it be better for preventing the routing loops if there
were some well-known bits in the 6rd prefix?

Best wishes,
Xiaohu 

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

---

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

Le 14 janv. 2010 à 11:04, Xu Xiaohu a écrit :

>>> "Additionally, a CE MUST allow packets sourced by the configured BR IPv4 Address"
>>> ", provided their IPv6 source address doesn't start with the 6rd prefix"
>>> 

Following a discussion with Mark, who also made this point, and who noted than without this provision IPv6-address spoofing possibility are still those of their embedded IPv4 addresses, not less, not more, _I withdraw the proposal_.
Thanks for the comment. 

>> know if you think we are missing some important normative language.

Agreed.
After discussing also this point with Mark, I agree to keep the text on this subject as is.

> were some well-known bits in the 6rd prefix?

This would IMHO add complexity, unnecessarily since routing loops are avoided with the described ingoing and outgoing filters in the BRs.

Best regards,

RD

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 19 Jan 2010 18:01:27 +0800

> -----邮件原件-----
> 发件人: Rémi Després [mailto:[email-masked]]
> 发送时间: 2010年1月14日 18:23
> 收件人: Xu Xiaohu
> 抄送: 'Mark Townsley'; [email-masked]
> >>> "Additionally, a CE MUST allow packets sourced by the configured BR
IPv4
> Address"
> Following a discussion with Mark, who also made this point, and who noted
than
> without this provision IPv6-address spoofing possibility are still those
of
> their embedded IPv4 addresses, not less, not more, _I withdraw the
proposal_.
> After discussing also this point with Mark, I agree to keep the text on
this
> subject as is.
> This would IMHO add complexity, unnecessarily since routing loops are
avoided
> with the described ingoing and outgoing filters in the BRs.

Sorry for late response. Will this approach of blindly filtering any packet
sourced from the BRs drop the normal tunneled packets mistakenly? 

Xiaohu

---

From: Rémi Després <[email-masked]>
Date: Tue, 19 Jan 2010 12:05:47 +0100

Le 19 janv. 2010 à 11:01, Xu Xiaohu a écrit :

>> This would IMHO add complexity, unnecessarily since routing loops
>> are avoided

The draft says:
   To avoid forwarding loops via other internal relays, the BR should
   employ outgoing and incoming IPv4 packets filters, filtering out all
   known relay addresses for internal 6rd BRs, ISATAP routers or 6to4
   relays, including the well known anycast address space for 6to4.

In my understanding, this will not filter any packet that should be forwarded.

RD

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 19 Jan 2010 20:58:33 +0800

> 发送时间: 2010年1月19日 19:06
> 主题: Re: routing loop issue//re: [Softwires] Please review 6rd
> 
> 

If there is a softwire tunnel between two BRs, wouldn't the packet tunneled
in the softwire be filtered blindly?

Xiaohu

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 29 Jan 2010 14:32:49 -0500

Happy to see this draft moving along and also publication of 5569, 
especially in the light of Comcast announcement of an end-user trial of 
IPv6 including 6rd.

I have read the draft and agree it is ready for WGLC, with a couple 
nits/questions

1. Intro:  Spell out the term Border Relay (BR) router on first use in 
intro; it is a new term being introduced here.
6. Address Selection:  is the statement meant to be normative SHOULD for 
6rd implementation, or is it just a hopeful observation (about other 
nodes behavior)?  I.e. one can expect 6rd delegated prefixes to be 
treated as native IPv6 addresses in address selection.
7.1.1.  6rdPrefixLength: why does DHCP bounds checking to allow 128 bits 
when the 6rd delegated prefix MUST be /64 or less?
8. Neighbor Unreachability Detection:  the statement about NUD could be 
stronger than "not recommended", especially since later it is stated 
that the CE MUST utilize a method which does not require special 
processing.  Also, the mechanism seems reasonable and flexible enough to 
be the required method rather than just "one such method."

edj

On 1/6/2010 2:59 PM, Mark Townsley wrote:
> Apologies for not meeting the "one week after Hiroshima" or even our 
> own self-imposed "before the Holidays" deadline. On the bright side, 
> we made it in before the pre-Anaheim deadline rush! Everyone should 
> have plenty of cycles to review for us right now. So, unless there is 
> any major objection, I'd like to request a Last Call.
>
> Many Thanks,
>
> - Mark

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]