Subject: [Softwires] SOFTWIRE working group last call on 6rd

From: "Durand, Alain" <[email-masked]>
Date: Mon, 22 Feb 2010 16:43:00 -0500

All -

We'd like to announce the softwire WG LC on the 6rd technology. I've copied
both SOFTWIRE and DHC mailing lists and solicit comments from both groups of
experts. The draft is here:

http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-07.txt

Please reply with comments to this thread by 2010.03.08 at 1700 PST

Thanks

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Feb 2010 14:58:48 -0700

On Feb 22, 2010, at 2:43 PM, Durand, Alain wrote:
> We'd like to announce the softwire WG LC on the 6rd technology. I've copied both SOFTWIRE and DHC mailing lists and solicit comments from both groups of experts. The draft is here:

The DHC part looks fine to me.   I enthusiastically support this in principle, but haven't reviewed the rest of the document.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Feb 2010 14:18:22 -0800

Alain,

As a first comment, the document is lacking a discussion of the
implications of having the BR use its anycast address as the source
address for the packets it relays.

Take for example the case of two BRs A and B that configure the
same IP anycast address, and a CE router C within the 6rd domain.
If BR A forwards packets toward C, but the packets are  lost in the SP
network, any resulting ICMPs could just as easily flow back through
BR B instead of A. Then, if the ICMPs don't contain enough information
for translation, BR B has no way to send a translated message back
to the original source and a black hole can result.

A solution to this would be to have BR's use their unicast address as
the source instead of an anycast address. In that case, CE router
C simply needs a way to discover the unicast addresses of all BRs
in the domain that configure the same anycast address. Such discovery
could be via the DHCP option, via DNS resolution of a FQDN, etc.

Fred
[email-masked]

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Durand, Alain
Sent: Monday, February 22, 2010 1:43 PM
To: softwires; DHC WG
Cc: David Ward; Ole Troan
Subject: [dhcwg] SOFTWIRE working group last call on 6rd

All -

Thanks

- Alain

---

From: Ole Troan <[email-masked]>
Date: Mon, 22 Feb 2010 23:28:58 +0100

Fred,

> BR B instead of A. Then, if the ICMPs don’t contain enough information

BRs are stateless. it does not matter which one the ICMP comes back to. if the ICMP message doesn't contain enough of the IPv6 packet there is nothing it can do, regardless of which one got the ICMP message. the use of the anycast address doesn't change that.

this exact issue shouldn't cause any issues. I've tried to think of any other issue with using the anycast as the source address, but I haven't come up with any. please let us know if you have others!

> A solution to this would be to have BR’s use their unicast address as

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Feb 2010 14:33:55 -0800

Ole,

> -----Original Message-----
> From: Ole Troan [mailto:[email-masked]]
> Sent: Monday, February 22, 2010 2:27 PM
> To: Templin, Fred L
> Cc: Durand, Alain; softwires; DHC WG; David Ward
> Subject: Re: SOFTWIRE working group last call on 6rd
> 
> Fred,
> 
> BRs are stateless. it does not matter which one the ICMP comes back to. if the ICMP message doesn't
> contain enough of the IPv6 packet there is nothing it can do, regardless of which one got the ICMP
> message. the use of the anycast address doesn't change that.

Then, there needs to be an analysis of the domain of
applicability. For example, a totally stateless 6rd
solution may be incompatible with SP networks in which
there may be ICMP messages that do not return enough
information for translation.

If the BRs were allowed to keep a small amount of state,
however, then they would be able to return appropriate
ICMPs to the IPv6 host on the outside even if the ICMPs
coming from the SP network on the inside did not include
enough information. Provided, that is, that the ICMPs
within the SP network are returned to the correct BR.
That is where a unicast source address instead of an
anycast one would steer the ICMPs to the correct BR.

Fred

> this exact issue shouldn't cause any issues. I've tried to think of any other issue with using the
> anycast as the source address, but I haven't come up with any. please let us know if you have others!
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 22 Feb 2010 23:46:46 +0100

Fred,

> anycast one would steer the ICMPs to the correct BR.

you are suggesting that a router should store a copy of every IPv6 header plus IP tunnel header for _every_ packet it forwards? and it should do this at wire-speed?
how much do you want to pay for this box? ;-)

are you talking about pre-RFC1812 IPv4 routers? in that case you wouldn't have enough information to correlate that accurately with the stored IPv6 packet in any case.

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Feb 2010 14:58:18 -0800

Ole,

> From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Monday, February 22, 2010 2:47 PM
> To: Templin, Fred L
> Cc: softwires; DHC WG
> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd
> 
> Fred,
> 
> you are suggesting that a router should store a copy of every IPv6 header plus IP tunnel header for
> _every_ packet it forwards? and it should do this at wire-speed?

No; that's not what I'm suggesting. I am suggesting that
for only those CEs for which ICMP unreachables are being
received that the BR store an MTU value and a reachable
flag. Then, when new packets come in from an outside IPv6
host, the BR can drop the packet and return an ICMP if the
packet would violate the MTU or if the CE has recently been
known to be unreachable. 

> are you talking about pre-RFC1812 IPv4 routers? in that case you wouldn't have enough information to
> correlate that accurately with the stored IPv6 packet in any case.

The BR does not need to know anything beyond the minimum
8 bytes in the ICMP; all it needs to know is whether the
CE is reachable, whether there is an MTU limitation on
the path, etc. Then, it can return suitable unreachables
or PTBs to the source host.

Fred

---

From: Ole Troan <[email-masked]>
Date: Tue, 23 Feb 2010 00:12:38 +0100

Fred,

> or PTBs to the source host.

sure, section 9.1 refers to how path MTU discovery is done for the tunnel. with the description in section 3.2.2 of rfc4213. sure, if you use PMTUD on a tunnel then if you use anycast SA on the BRs, the MTU cache would have to be populated on both.

I know you are doing a heroic effort with MTU issues in the Internet, but I feel we have been through most of the MTU discussions already during the discussions on previous revisions of the document. do you feel we need to rehash them again?

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Feb 2010 15:34:01 -0800

Ole,

> Sent: Monday, February 22, 2010 3:13 PM
> To: Templin, Fred L
> Cc: softwires; DHC WG
> sure, section 9.1 refers to how path MTU discovery is done for the tunnel. with the description in
> section 3.2.2 of rfc4213. sure, if you use PMTUD on a tunnel then if you use anycast SA on the BRs,
> the MTU cache would have to be populated on both.

I could not parse "populated on both" - which do you mean by
"both"? I assume the BR A is one of the both, but what is
the other? BR B? (If so, it is only BR A and not BR B that
needs to maintain state if A uses its unicast address
instead of the anycast.)

Also, this is not just about PMTUD; it is about any unreachable
that may come from the SP network (e.g., host unreachable,
protocol unreachable, etc.).
 
> I know you are doing a heroic effort with MTU issues in the Internet, but I feel we have been through
> most of the MTU discussions already during the discussions on previous revisions of the document. do
> you feel we need to rehash them again?

The larger MTU discussion should be taken up on a
different thread. 

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Feb 2010 10:23:24 -0800

Ole,

I think the document is also lacking an analysis on the
implications of 6rd using anycast in the presence of IPv4
fragmentation.

When CE C sends IPv6-in-IPv4 encapsulated packets to the
6rd anycast address, and it sets DF=0 on the outer header,
there is a chance that if fragmentation occurs in the SP
network that the fragments of the same datagram could go
to different 6rd BRs. If that happens, some pieces of a
fragmented packet could end up in the reassembly cache of
BR A and others in the reassembly cache of BR B. But, as
long as any routing oscillations are short-lived, this
should not present a major problem since the reassemblies
at A and B will simply time out, and C will simply notice
that a packet has been lost.

When multiple IPv6 sources outside the 6rd domain (e.g, S1
and S2) send IPv6 packets toward C, however, the flow from
S1 may traverse BR A while the flow from S2 may traverse BR
B. In that case, if A and B are using the 6rd anycast address
as the outer IPv4 source address, and if there is chance of
fragmentation within the SP network, the fragments of S1's
packets could easily be misassociated with the fragments of
S2's packets. In that case, there is very real opportunity
for data corruption which could escape detection by upper
layer checksums.

This suggests to me that CE C SHOULD NOT set DF=0 in the
IPv6-in-IPv4 packets it sends to the 6rd anycast address
and that BRs A and B MUST NOT set DF=0 in the IPv6-in-IPv4
packets they source from the 6rd anycast address.

For further consideration, I have seen advertisements
to the effect that certain SPs will soon be offering
much higher data rate services. In that case, there
may be opportunity for undetected data corruption when
DF=0 even if the 6rd anycast address is not used for
either the source or destination.

This suggests to me that setting DF=0 should be
strongly discouraged within 6rd domains. This also
means that the domain of applicability of 6rd should
be restricted only to those networks that can pass
minimum-MTU IPv6-in-IPv4 packets (1280 + 20) without
fragmentation in the network. Unless of course SEAL
is used; in that case, DF=0 would be appropriate and
there is no limitation to the domain of applicability.

Fred

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 23 Feb 2010 12:36:18 -0800

> Please reply with comments to this thread by 2010.03.08 at 1700 PST

I have reviewed the new DHCPv4 option definition in this draft.

In this text from section 7.1.1;

   No more than one instance of the OPTION_6RD DHCP option MUST occur in
   a given DHCP packet.

I'm glad there is no discussion of "option fragmenting".  I think this
text is simple and clean for that purpose.

I'm a little concerned that the draft makes no mention of the DHCPv4
Parameter Request List (PRL) option, and in its current state (quoted
above) slightly infers that the option will magically appear in DHCP
responses in any networks where the 6rd service is available?

I would like to see a normative requirement for the client to place
the option on its PRL ahead of this sentence, or a non-normative aside
after it (", provided the client requested the option on its Parameter
Request List option." or similar), but I also appreciate if the author
also thinks of this mechanism as "how DHCP works".

In my opinion in this case remembering to place the option on the PRL
is an often overlooked detail, as there are many clients today that
accept certain options without explicit request, and so it's good to
provide implementers with a reminder.

Aside from this more-or-less grammatical and editorial consideration,
I have no other issue with the structure of the option or accompanying
text, and I support the draft's advancement.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/

---

From: Ole Troan <[email-masked]>
Date: Tue, 23 Feb 2010 23:28:21 +0100

David,

thanks for the review. I have to admit that I didn't know the PRL option existed.

something like this?

  The CE SHOULD include a Parameter Request List Option [RFC2132] for
  the OPTION_6RD.  No more than one instance of the OPTION_6RD DHCP
  option MUST occur in a given DHCP packet.  Provisioning of a CE
  router connected to multiple 6rd domains is outside the scope of this
  protocol specification.

Best regards,
Ole

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Feb 2010 14:37:19 -0800

David,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of David W. Hankins
> Sent: Tuesday, February 23, 2010 12:36 PM
> To: Durand, Alain
> Cc: softwires; DHC WG; David Ward; Ole Troan
> Subject: Re: [dhcwg] SOFTWIRE working group last call on 6rd
> 

I didn't know that the DHCPv4 option you are referring to
is known as "PRL" - is that a commonly-used acronym for
the option? As it happens, ISATAP uses the acronym "PRL"
to refer to the Potential Router List, which is an entirely
different concept.

Taking a new look at the latest 6rd draft, I now see
that the DHCP option for 6rd supports a list of border
router addresses instead of a single address as was in
the previous versions - perhaps it should be called the
"6RL"? I also see the text:

   "A detailed description of CE behavior using multiple BR IPv4
   addresses is left for future consideration.  In such a case, a CE
   MUST support at least one BR IPv4 address and MAY support more than
   one."

I think it would be better if that text were changed to
something like:

   "The first IPv4 address in the 6rd Router List (6RL) is the
    anycast address for the 6rd domain. Any additional IPv4
    addresses in the 6RL are the unicast addresses of BRs
    that also configure the anycast address."

Then also under Section 9.2, change:

   "Additionally, a CE MUST allow packets sourced by the configured BR
   IPv4 Address."

to:

   "Additionally, a CE MUST allow packets sourced by any of the
    IPv4 addresses in the 6RL."

Then in Section 7.2 change:

   "If the BR IPv4 address is
   anycast the relay MUST use this anycast IPv4 address as the source
   address in packets relayed to CEs."

to:

   "The BR MUST use its 6RL unicast IPv4 address as the source
    address in packets relayed to CEs."

Fred

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 23 Feb 2010 14:47:48 -0800

> to refer to the Potential Router List, which is an entirely

Yes, in context of DHCP the term "PRL" is often used in shorthand.
Because (especially short) acronyms can be severely overloaded, it is
best to clarify which meaning of the acronym you intend the first time
it appears in any document.

In DHCPv6 there is the similar "Option Request Option" which is also
frequently referred to either by its protocol label name "OPTION_ORO",
or simply in discussion as "ORO."

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 23 Feb 2010 14:59:09 -0800

>   router connected to multiple 6rd domains is outside the scope of this

Yes, I think that would be entirely satisfactory.  I'm sorry such a
minor editorial item comes so late, I admit that in previous reviews I
was focused on the option's structure and not so much the accompanying
text.

Minor discussion for edification;

Normally I would want that to be a 'MUST', in a draft describing just
the option.  A client implementing the option has no sensible way to
expect a value will be returned if it isn't on the PRL (unless the
client sends no PRL, which isn't very realistic today).

But because this draft does much more than measure conformance to the
option specification, I think SHOULD is entirely appropriate.

---

From: Ole Troan <[email-masked]>
Date: Wed, 24 Feb 2010 00:04:25 +0100

> option specification, I think SHOULD is entirely appropriate.

I took the SHOULD from RFC3315, which has that for the ORO option. I couldn't find any other DHCP option RFCs with SHOULD or MUST for the PRL option.

cheers,
Ole

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 23 Feb 2010 16:33:47 -0800

On Wed, Feb 24, 2010 at 12:04:25AM +0100, Ole Troan wrote:
> I took the SHOULD from RFC3315, which has that for the ORO option. I
> couldn't find any other DHCP option RFCs with SHOULD or MUST for the
> PRL option.

I think many option RFC's do not mention the PRL explicitly (how the
client gets the option is a basic DHCP protocol feature in that
sense), but in this case I'm a little uncomfortable because the
language of the MUST about there being one option is so specific.

I think in RFC 3315's case the SHOULD is because the client can elect
not to send the ORO at all.

I wonder if the reason that there be at most one option is because you
may be aware of 'option fragmenting'?  In DHCPv4, multiple options of
the same option code are concatenated together in order to support
options whose data is longer than 255 octets (and it is also handy in
letting smaller options be split along the options/file/sname fields
if out of space and using option overloading, but these details are
why I don't like busying a new option specification with this
discussion; it gets confusing fast).

It may be simpler to say;

  Because the OPTION_6RD contains one IPv4MaskLen/6rdPrefixLen/6rdPrefix
  block, and because DHCP cannot convey more than one instance of an
  option, OPTION_6RD is limited to provision at most a single 6rd
  domain.  Provisioning of a CE router connected to multiple 6rd domains
  is outside the scope of this protocol specification.

And avoid the normative language entirely (leave all those mechanics
entirely up to RFC 2131 conformance)?

Anyway, it is just an idea.  I'm quite happy with there just being a
reminder about the PRL with the existing text.

---

From: Alexandre Cassen <[email-masked]>
Date: Wed, 24 Feb 2010 11:04:36 +0100

Hi,

On Mon, 22 Feb 2010 16:43:00 -0500, Durand, Alain wrote:
> We'd like to announce the softwire WG LC on the 6rd technology. I've
> copied both SOFTWIRE and DHC mailing lists and solicit comments from
> both groups of experts. The draft is here:
>

This document truly depict what we are running into production in our
backbone here. I strongly support it!

I read some post on the ML regarding fragmentation and MTU related.
IMHO, section 9.1 is enough explicit, anyone playing around with
encapsulation will face at one point MTU issues and fragmentation, it is
really common. Any operational networking guy will/have to keep in mind
this MTU stuff while designing/setting up its encapsulation
architecture. What is important here, 6rd is operating inside a specific
routing domain so that if there is MTU/fragmentation issues then it is
networking domain designer job/responsibility to fix it ! if networking
design has been made into a crappy way then it will transitively operate
into a crappy way too. IMHO, it should certainly not be the focus of an
operational protocol draft, like 6rd, to provide a networking course.

In our production env, MTU is set to 1480 at CPE side.

regs,
Alexandre

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 24 Feb 2010 09:08:49 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandre Cassen
> Sent: Wednesday, February 24, 2010 2:05 AM
> To: [email-masked]

But, what do you call it if the customer sets up a big
network with lots of 1500+ links internally (maybe even
as big as 9K). Do you call that crappy too?

Fred

---

From: <[email-masked]>
Date: Thu, 25 Feb 2010 09:05:04 +0100

Hi,

We have succesfully shown interoperability between the 6RD CEs of two different manufacturers (integrated into VDSL routers) and the 6RD border relays of yet another two manufacturers. All implementations run smoothly, and we have not discovered any issues with the 6RD technology. 6RD fits very well into a service provider enironment, allowing for a cost efficient IPv6 deployment at a large scale. I stronlgy support this draf'ts advancement to standards track.

We are running a setup with redundant border relays. At first, we had some issues with packet reordering when both relays had the same IGP metric, and load balancing was performed on a per packet basis. This adversely affected the TCP througphut of Windows XP. Other OS did not suffer from this. We have now changed from load balancing to an active/standby configuration.

Best regards,
Martin Gysi, Swisscom

From: [email-masked] [mailto:[email-masked]] On Behalf Of Durand, Alain
Sent: Monday, February 22, 2010 10:43 PM
To: softwires; DHC WG
Cc: Ole Troan
Subject: [Softwires] SOFTWIRE working group last call on 6rd

All -

Thanks

- Alain

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Feb 2010 09:25:29 -0800

> In our production env, MTU is set to 1480 at CPE side.

Here's another thing to consider wrt the 1480. Once the
CPE statically sets a 1480, it will be next to impossible
to get it to set something larger in the future. Better
would be to initially have the CPE set an infinite MTU
on the tunnel interface, set DF=0 on all tunneled packets,
and have the tunnel far end report any fragmentation.
(Note that I *did not* say that the tunnel far end has
to reassemble.)

That way, if the operator has not done something crappy
there is a very good change that 1500+ packets will get
through and not be blocked by the overly-conseravative
1480.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Feb 2010 09:25:47 -0800

Regarding the load balancing issue, if the CE routers are exposed to
the list of unicast addresses of BRs they can use Equal Cost
MultiPath (ECMP) to direct the load balancing if any load balancing
is desired. This would allow multiple active BRs (as opposed to
active/standy) and still give a nice distribution of traffic without
packet reordering issues.

Fred

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, February 25, 2010 12:05 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd

Hi,

Best regards,
Martin Gysi, Swisscom

All -

Thanks

- Alain

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Feb 2010 09:09:23 +1300

Hi Fred,

On 2010-02-26 06:25, Templin, Fred L wrote:
> to get it to set something larger in the future. 

So what? 6RD is definitely a transition technique running over
legacy IPv4. I think we have running code experience that
defaulting the MTU to 1480 will work in most normal circumstances,
whereas reliance on PMTUD is known to be problematic. If 1480
becomes an issue, it will become part of the motivation to upgrade
to native IPv6.

    Brian

Better

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Feb 2010 13:06:59 -0800

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, February 25, 2010 12:09 PM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]
> whereas reliance on PMTUD is known to be problematic.

To be clear, I am not asking for reliance on PMTUD. I am
instead asking for reliance on something better than that
(SEAL) so that no artificial limits like 1480 are needed.

> If 1480

This kind of argument strikes me as a business-oriented
rather than technical viewpoint on the problem space. We
now have technologies by which we can deploy tunneled
service that is as good as or perhaps even better than
native (and yes, I include 6rd as part of the solution).
So, why not have a once-and-done deployment now as opposed
to putting up a temporary service which we know will need
replacement in the near future? So that network equipment
vendors can sell more products and services?

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Fri, 26 Feb 2010 01:43:51 +0100

Fred,

> vendors can sell more products and services?

I do agree that MTU handling is a general problem, and not even just for tunnels.
I thought we agreed while discussing earlier versions of this draft, not to encumber the 6rd specification with the general solutions to these MTU problems.

6rd references RFC4213 for most of the tunnel mechanics. could we move that debate to rfc4213bis or something?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 26 Feb 2010 01:44:27 +0100

Fred,

> packet reordering issues.

if you do per-packet load balancing you could get re-ordering in any place in the network, assuming multiple paths. regardless of what the CE does.
it would of course be beneficial if intermediate routers manage to do flow based load sharing also for tunneled packets.

in any case one could adjust the IGP metrics for the anycast routes to avoid any load balancing between them from a single CE.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Fri, 26 Feb 2010 08:03:51 +0100

Hi Fred, 

Although the SEAL approach has IMHO some merit of its own for some generalized tunneling scenarios, using it  in 6rd would defeat the objective of simplicity for "rapid deployment" of IPv6.

The draft should therefore proceed as is on this subject. 

RD

>> (SEAL) so that no artificial limits like 1480 are needed.

See above.

> I thought we agreed while discussing earlier versions of this draft, not to encumber the 6rd specification with the general solutions to these MTU problems.

This is IMHO the right approach.

---

From: Satoru Matsushima <[email-masked]>
Date: Sat, 27 Feb 2010 12:29:01 +0900

Hi,

I got good result of 6rd implementation which based on this document, and interoperability test 
with some manufactures. I strongly support this document to advance.

FYI, 
Softbank BB and BBIX, which are Japanese service providers, adopt 6rd to provide IPv6 connectivity.

--
Satoru Matsushima

---

From: Gabi Nakibly <[email-masked]>
Date: Sun, 28 Feb 2010 23:44:08 -0800 (PST)

Hi all,
I would like to comment on the loop avoidance issue addressed in the Security Considerations section.
First, I agree that the the best mitigation measure here for loops via external relays is to simply drop at the border of the 6rd domain packets sent from or destined to a 6rd BR.
Second, regarding loops via internal relays the draft mentions that:

   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.

Does the SP necessarily knows of every ISATAP router or 6to4 relay deployed in the 6rd domain? After all, a customer can deploy an ISATAP router or even a 6to4 relay for that matter without the knowledge of the SP, while using a configured tunnel (by a tunnel broker) for its IPv6 connectivity.
I suggest to keep the filtering of internal 6rd BRs. But to avoid loops via internal ISATAP routers or 6to4 relays, I would suggest employing the destination/source address check described in Section 3.1 in http://tools.ietf.org/html/draft-nakibly-v6ops-tunnel-loops-01 we have recently submitted. It is not a perfect solution, and indeed it should be updated in case other types of automatic tunnels come up, but it does the job for ISATAP and 6to4 loops without demanding a knowledge of every internal ISATAP router or 6to4 relay.

Other than this I fully support this draft for advancement.

Gabi

________________________________
From: "Durand, Alain" <[email-masked]>
To: softwires <[email-masked]>; DHC WG <[email-masked]>
Cc: Ole Troan <[email-masked]>
Sent: Mon, February 22, 2010 11:43:00 PM
Subject: [Softwires] SOFTWIRE working group last call on 6rd

All -

Thanks

- Alain