Re: [v6ops] 6204bis and WAN disappearing

["Weil, Jason" <[e-mail]>]

Might as well continue the age old discussion for us new to the game and
trying to actually implement this stuff...

On 2/22/12 9:02 AM, "Ted Lemon" <[e-mail]> wrote:

>Various people have made the claim that continuing to use the GUA after
>its lifetime expires is okay as long as you remain disconnected, but this
>isn't correct.
>
>The reason it isn't correct is that a GUA, used beyond its valid
>lifetime, has the potential to be immediately invalidated when the WAN
>reappears.   When I say potential, it might seem like I mean that it's
>something that could happen, but is unlikely.   But we as protocol wonks
>have no way to make that statement, because it depends on circumstances
>we don't control‹it depends on the provider's upstream policy.
>
>So this means that if we arrange to kill the GUA when the WAN comes back,
>if the GUA is no longer valid, then perfectly valid in-home streams will
>be interrupted.   We might say "oh, that's no problem, let the streams
>that are running keep using the GUA."
>
>This is still a problem, though, because a device configured with a GUA
>whose lifetime has expired will not know that its lifetime has expired,
>because there is no way to communicate this: in IPv6, an address is valid
>or it is not.   We do get to play with preferred versus valid, and maybe
>we could deprecate the address and hope that the node wouldn't try to use
>it to connect anymore, but there's no mechanism for doing this in the
>IPv6 protocol suite.
>
>So it's quite likely that when the WAN does reappear, the device will try
>to use its GUA to communicate with devices off the local wire.   If the
>GUA is no longer valid, it will fail.

OK I was following but now you are losing me. As soon as the WAN comes
back up, the CE Router advertises itself as a Default router once again.
If the GUA remains unchanged per a successful Rebind of the IA-PD then
communication proceeds off the wire successfully. If the prefix changes or
is no Longer Valid (see Side Question) communication off the wire breaks.
How is this any different from any renumbering event today which requires
breaking old connections?

I see a valid point in here for using ULA for communication to avoid a
renumbering event breaking in-home sessions, but I fail to see how using a
GUA after its lease lifetime expires prior to link up resulting in any
different action than using a GUA whose lease is still valid but which is
no longer routed due to a renumbering event encountered when the link
comes up assuming no explicit reply to the REBIND with valid timer equal
to 0?

Side Question: Is the expected response to a Requesting Router Rebind
event on link bounce for the Server to respond with NotOnLink status as
per 18.1.8 of RCC3315 CONFIRM process? This is for a Confirm messages but
since Confirm is not supported in RFC3633 it is a bit unclear what the
Requesting Router is expected to do next, but I personally would expect a
new SOLICIT.


>
>Whereas a ULA has limited scope; if a device is configured with a ULA,
>and the WAN comes back, then the device can immediately get a valid GUA
>and start communicating with it.   Because all in-home connections are
>using the ULA, they are not interrupted.

>
>Of course, in-home connections that started out using the GUA and
>survived the loss of the WAN connection will die when the valid lifetime
>of the GUA expires.   This is a good reason to try to arrange for all
>in-home connections to use ULAs always, even when we have a WAN
>connection.
>
>I realize I'm just reiterating things that have been said before, but
>given that we are still hearing the notion of keeping the GUA on WAN
>loss, I think it's worth walking through the argument again.
>

Jason


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.