Subject: Re: [Softwires] I-D Action:draft-donnerhacke-softwire-ipv6-6to4-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 May 2010 22:29:17 +1200

>       6to4 prefixes more specific than 2002::/16 are allowed to be
>       propagated in native IPv6 routing, as long as the more specific
>       matchs exactly the mapped most aggregated IPv4 route originated by
>       the same AS. 

This is a really, really bad idea, for the reason given in RFC3056:

      6to4 prefixes more specific than 2002::/16 must not be propagated
      in native IPv6 routing, to prevent pollution of the IPv6 routing
      table by elements of the IPv4 routing table.

That is a much more important issue than the fact that 6to4 doesn't work
well for users whose ISPs haven't deployed a 6to4 relay (and announced 2002::/16
locally). ISPs do need to pay attention to filtering rules for 2002::/16
announcements.

   Brian

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 28 May 2010 09:43:19 -0400

I agree with Brian. If a SP wants to provide a managed 6to4 service, 6rd is
the way to go. SPs shouldn't try to solve the broken 6to4 problem by
injecting v4 information to the global v6 routing table.

Yiu

On 5/28/10 6:29 AM, "Brian E Carpenter" <[email-masked]> wrote:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 May 2010 04:22:23 +1200

Lutz,

On 2010-05-28 23:51, Lutz Donnerhacke wrote:
> On Fri, May 28, 2010 at 10:29:17PM +1200, Brian E Carpenter wrote:
> Did you notice, that this particual paragraph in RFC3056 is to be changed
> by this draft? The whole draft is about why this change is necessary and how
> can it be done.

And that is where I disagree profoundly. Encouraging longer 2002:: prefixes
is absolutely the wrong thing to do for the reason stated in RFC3056.
We don't want to see the IPv6 world filled up with junk from
IPv4 (or to import v4 BGP filtering rules into v6 as a result).

Also, the correct operation of 6to4 depends on universal visibility
of 2002::/16, so that every native v6 host can send to every 6to4 router.
Announcing specifics within that prefix is useless to native v6 hosts
that need to send packets elsewhere, so you can't suppress the /16
even if you add more specifics.

>    In order to provide stable routing over their IPv4-only backbones
>    ISPs prefers to keep the 6to4 and Teredo traffic as long as possible
>    in the IPv6 network. 

I don't see why this has any relevance to v4 stability. Actually the
best service to your users comes from doing the exact opposite: provide
a local 6to4 relay which is the destination for 2002::/16, encapsulate
in IPv4 as near the source as possible, and get rid of the v4 packets
as soon as possible.

>    6rd [I-D.ietf-softwire-
>    ipv6-6rd] with allows every ISP to assign it's own unicast prefix
>    similar to 2002::/16. This is a huge waste of address space.

No it isn't. It's actually a trivial amount of space within any reasonable
ISP v6 allocation. Also, the great advantage of 6rd is that it adds
no BGP4 prefix.

The right thing is to limit the scope of 2002::/16 announcements so that
traffic sent to 6to4 destinations is encapsulated in IPv4 as near the
source as possible.
> 
> A proposed alternative is to hand out every ISP a separate /20-IPv6 block,
> who want's to deploy more stable 6to4. So routing table size is clearly not
> an issue: 6rd generate a lot of new long term routes while this draft
> generates the same amount of (filterable) routes within a common prefix.

You have clearly misunderstood 6rd. It doesn't generate a single new route
in BGP.

>> well for users whose ISPs haven't deployed a 6to4 relay (and
>> announced 2002::/16 locally).
> 
> Please do not joke this way. If the ISP announces 2002::/16 and does not run
> the approbriate service for, there is something terribly wrong.

The problem is when ISP A carries a route to 2002::/16 that they got from
ISP B, but ISP B does not accept external traffic to their relay.
In such a case both ISPs are wrong - B should not have announced in BGP,
and A should have filtered the announcement. But as said above, you can't
fix that by longer prefixes, because they break 6to4 anyway.

   Brian

> 
>> ISPs do need to pay attention to filtering rules for 2002::/16 announcements.
> 
> Of course. That's part of the draft.
> 
>