Re: [v6ops] 6204bis and WAN disappearing

[Wuyts Carl <[e-mail]>]

Well, you have people pro and contra ULA-support.  Lots of people question the real need for ULA as well.
I tend to agree you don't really need it, at least not in the most common deployments (we're mainly doing residential CPEs), although our CPE supports it today (configurable).  It indeed adds a little extra complexity, as you get more and more addresses.  In a residential scenario, you often only have 1 LAN segment, hence the need for ULA becomes less important I guess.

It's there for people who want to use it, I guess, and can be maybe useful in some more advanced roll-outs or future home-net solutions with multiple LAN segments in the home.  As we're deploying in a managed CPE, it's up to our customer to either enable or not the ULA creation on the advertising interface(s).

Regs
Carl



From: [e-mail] [mailto:[e-mail]] On Behalf Of Rémi Després
Sent: donderdag 23 februari 2012 15:08
To: Ted Lemon
Cc: [e-mail]; [e-mail]
Subject: Re: [v6ops] 6204bis and WAN disappearing


Le 2012-02-23 à 14:37, Ted Lemon a écrit :


On Feb 23, 2012, at 3:26 AM, Rémi Després <[e-mail]<mailto:[e-mail]>>
 wrote:
Even if it doesn't, it isn't a serious problem: the host is informed in ICMPv6 that unreachability of the destination is due to ingress or egress filtering (Type 1 code 5 per RFC4443).
What it does next is implementation dependent, but checking its source address makes sense.

This is true, but it leaves the problem of what happens to net-local communication when this happens.

If local communication uses GUAs and, as I suggest, GUAs remain valid in case of WAN-link failure, local communication continues undisrupted.


 As a reminder, the original point I was making was simply that it is in fact necessary, or at least desirable, to use ULAs for internal communication.

AFAIK, it creates more problems than it solves.
My home site uses IPv6 without ULAs. It has no problem, and I don't know how I could use ULAs today if I wanted to.

Wanting to use ULA it in my understanding against the keep-it-simple principle.


Besides, this only happens when ISPs change IPv6 prefix assignments, which is always a problem for external connections.

If this is true, it seems like a pretty big problem.   It's bad enough when ISPs change my IP address; now they are going to renumber my entire network?

At least on a single-link, changing an IPv6 prefix isn't more complex than changing the external address of a NAT44: It breaks current connections but everything else is automatically fixed.

For instance, when Free obtained a /26 instead of its initial /32, in 2008, my IPv6 prefix changed but I didn't notice it before examining which IPv6 address (GUA) my Mac was using.


DHCP has generally been designed to prevent this: when you renew your address, you get the same address, not a different one, and when you renew your prefix, the same is true.

If I get it right, you assume that each host has both a ULA, for local sessions, and a GUA, have Internet e2e transparency.
But, as noticed, not all hosts can do this, so that this model less workable than the current one where only GUAs are used.

RD