Subject: [DNA] Re: About draft-ietf-dna-cpl-00.txt

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Jul 2005 01:31:11 -0700

Greg Daley wrote:
> Dear Erik and JinHyeock, 
> 
> I've recently read through CPL, and am pleased with how it is
> shaping up. 
> 
> While reading through, I noticed some minor issues which 
> may need to be considered:

Thanks for your careful read - We've tried to fold in improvements on 
all of these points in the new version of the draft.

> Second Last paragraph on Page 6 (Section 2.3):
> 
> "...
>    Otherwise, to make matters certain, the host may need at least to
>    wait for more than the first RAs, or additionally, perform multiple
>    RS/ RA exchanges after the hint.  The first level of trying harder is
>    to, after the RS transmission,  wait for all RAs that would have been
>    triggered by the RS.  The second level of trying harder is to send
>    multiple RSs (and waiting for the resulting RAs).
> ..."
> 
> I think that this paragraph needs to be more direct:
> 
> Suggest:
> 
> "...
>    Otherwise, to make matters certain, the host may need to attempt 
> further
>    procedures.  A first step to clarify link identity is to wait for 
> all RAs
>    which would have been sent in response to the RS.   A further step 
> is to send
>    multiple RSs (and wait for the resulting RAs).
> ..."

I think your suggested text makes things more clear.

> Section 4.4:
> 
> After the last paragraph, it is not clear if the link-layer
> indications reset the number of router solicitations for
> MAX_RTR_SOLICITATIONS comparison.
> 
> I'd consider adding the following paragraph.
> 
> "...
>  
>    Note that if link-layer indications are reliable, a host can
>    reset the number of sent Router Solicitations to 0, while still
>    maintaining RTR_SOLICITATION_INTERVAL between RSs.
> 

Makes sense.

> Page 15 Paragraph 2, Section 4.5:
> 
> "...
>    It is possible that the above comparison will result in matching
>    multiple Candidate Link objects.  For example, if the RA contains the
>    prefixes P1 and P2, and there is one Candidate Link object with P1
>    and P3 and other Candidate Link object with P2 and P4.  This should
>    not happen during normal operation, but if links have been renumbered
>    or physically separate links have been made into one link (before the
>    lifetimes in the Candidate Link objects expired), then the host could
>    observe this.  The most sensible action would be for the host to
>    merge all such matching Candidate Link objects together with the
>    information in the receive RA and make this the new CCL.  Doing this
>    merging correctly probably requires that each Candidate Link object
>    contains the time it was last updated by a RA, so that more recent
>    information can override older information.  Note that this case is
>    one reason one needs to be concerned about security issues when
>    Candidate Link objects are shared across multiple interfaces
> ..."
> 
> * "The most sensible action would be for " is actually debatable, since
>   this may lead to false detection in the case that existing CCLs hold
>   out-of-date information (if a no-longer present prefix is retained).
 >
> s/The most sensible action would be for/One possible action would be 
> for/

I don't mind using your suggested change (and 01 already does) but I'd 
like to understand more about the case where this would cause a problem.
The draft recommends that a Candidate Link object not be retained for 
more than 90 minutes, thus as long as a prefix isn't removed from one 
link and added/assigned to another link in less than 90 minutes then 
this shouldn't be a problem, right? (That's what we call the flash 
renumbering and reassignment case.) If the prefix is allowed to expire 
(lifetimes dropping to zero) before it is removed and reassigned to 
another link, there should never be any confusion.

> * There's a sentence at the bottom of the paragraph:
>   "Note that this case is one reason ...multiple interfaces"
> 
> This is inappropriate given the location, and the fact that sharing
> between interfaces has already been prohibited due to security
> reasons (which override the later consideration).  The sentence
> should be deleted to ensure that people don't get distracted
> from the main content.

Good catch. The document had become internally inconsistent on this point.

> Page 15 Paragraph 4+5, Section 4.5:
> 
 > [...]
> 
>   The first paragraph is incorrect since it forgets (or misstates) when 
> the
>   CCL is complete that any received RA should be treated as from a
>   separate link if there are no prefixes in common with the CCL.
> 
>   Suggested Text (including paragraph boundary movement):
> 
> "...
>    When the first RA afte a link UP notification contains prefixes 
> which 
>    are disjoint from those in the CCL, it may not be immediately obvious
>    whether the host has moved or not.   Where the CCL is believed to be
>    complete, though, any advertisement which arrives that does not 
> contain
>    common prefixes with the CCL can be assumed to be a link change in 
>    accordance with section 4.6.  Otherwise, the host needs to create a
>    new CCL with the new router's advertisement.  This CCL should not
>    yet be treated  as if it belongs to a new link though, and the
>    operations defined in 4.6 should not yet occur.  Instead, the host
>    waits a minimum it waits for 4 seconds, and RAs that are received 
> during
>    that time interval are processed as specified above.
> 
>    This processing might result in finding a prefix in common between a
>    Candidate Link object and the CCL, in which case the host knows
>    whether and to which link it has moved.  But should the 4 seconds
>    expire without any common prefix, then it will conclude that it has
>    moved to a new link and inform the rest of the host of the movement
>    (Section 4.6.)  Note that the arrival of a new link UP notification
>    during the 4 second timer must prevent the timer from firing.  In
>    this case the host might yet again have moved so it is necessary to
>    restart the process of inspecting the RAs.
> ..."

I edited your suggested text and created a hybrid of it and the old 
text, so that we capture the case when the host views its prefix list as 
complete.
[The 01 draft also has a RS_RA_count conceptual variable which is used 
to determine when the prefix list is viewed as complete.]

> Page 16 Last paragrpah of section 4.5:
> 
> 
> "...
>    Subject to local policy, and perhaps also the host's knowledge of the
>    packet loss characteristics of the interface or type of L2
>    technology, the host can try harder than just waiting for 4 seconds.
>    It is allowed to multicast up to MAX_RTR_SOLICITATIONS [1] RS
>    messages spaced RTR_SOLICITATION_INTERVAL apart.  In the most
>    conservative approach this means a 12 second delay until the host
>    will declare that is has moved to a new link.  Just as above, this
>    process should be terminated should a new link UP notification arrive
>    during the 12 seconds.
> ..."
> 
>    This text needs to be made more direct:
> 
> s/can try harder than just waiting for 4 seconds./can send Router 
> Solicitations in
> order to gather information./

ok

    Erik

---

From: Greg Daley <[email-masked]>
Date: Tue, 19 Jul 2005 11:11:06 +1000

Hi Erik,

Thanks for your work in getting -01 out. It looks good.

Below I've gone into further detail about my confusion about
flash renumbering and the 90 minute window.

Erik Nordmark wrote:
[cut]
>> s/The most sensible action would be for/One possible action would be for/
> 
> 

I've been thinking about this more recently since looking
at the implementation of cpl-00 (I've not got the 90 minutes
timers though).

I think you're right about the lifetimes counting down to zero (based
on the real time counters from Section 4.1).  These should supercede
the 90 minute cache time, where a prefix is withdrawn from a link.

For example with DHCPv6 PD, the advertised lifetimes of prefixes in
RAs decrement as the DHCP lease time reduces, so that the prefix
can't be configured beyond it lifetime.   As soon as the prefix
is not valid any longer on a link, it can be immediately allocated
to another link (with no overlap time, since the prefixes are expired
on the old link).  I guess this could become a fairly common case.

If you're only using PIOs for prefix lifetimes, then the lifetimes
should count down to zero at approximately the same time, without
any problems.

Only if a prefix is assigned to a new link before the expiry of the
prefix on the old link, would the 90 minute timer come into use.

So is flash renumbering really about allocating a prefix to another
link before expiring the lifetime on the existing link's routers?

In that case, the 90 minutes are sufficient only if deployers
can be made to comply with that period of non use (or non redeployment)
for the prefix.

I think the flash renumbering concept needs to be well defined
(possibly separately), and discussed in order to gain a wider
consensus that it's a problem we need to solve, and if the
90 minute hold-down before reallocation is the right way to solve it.

At this stage, I've only seen flash renumbering described in a
DNA context, so it would be good to figure out if any other WGs
are likely to have the same interest or problems.

Your references would be helpful here.

[cut]
>>   The first paragraph is incorrect since it forgets (or misstates) 
>> when the
>> which    are disjoint from those in the CCL, it may not be immediately 
>> obvious
[cut]

I think the text in -01 is good.

Thanks,

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Jul 2005 01:11:00 -0700

> Thanks for your work in getting -01 out. It looks good.

Thank Brett!

> the 90 minute cache time, where a prefix is withdrawn from a link.

Yes, it should be the min of the 90 minutes and the advertised valid 
lifetime.

> prefix on the old link, would the 90 minute timer come into use.

Yes.

> link before expiring the lifetime on the existing link's routers?

The loose definition I've been using for "flash renumbering" (as opposed 
to more gentle forms of renumbering) is where the prefix is suddenly 
withdrawn i.e. the valid lifetime suddenly drops from a large value 
(could be 30 days, or a few hours) down to zero.

More gentle forms of (planned) renumbering would be when the preferred 
and valid lifetimes are allowed to decrement in realtime i.e. with an 
initial valid lifetime of X days, it is known X days in advance that the 
prefix will be removed.

The problematic case shows up when there is flash renumbering followed 
by (more or less) immediate reassignment of the removed prefix to 
another link.
One could argue that folks shouldn't do that, but it would still be nice 
to have some safety so that, should it be done, a DNA host isn't in some 
confused state for a long time (e.g., 30 days with the default RFC 2461 
timers).

> can be made to comply with that period of non use (or non redeployment)

Yep.

> 90 minute hold-down before reallocation is the right way to solve it.

FWIW I think this might be one reason that Keith Moore was concerned 
about using prefixes for DNAs purpose.

> are likely to have the same interest or problems.

There hasn't been another place it has come up, because there hasn't 
been another thorough effort to handle movement.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Jul 2005 02:02:46 -0700

>> Thanks for your work in getting -01 out. It looks good.

Sigh - too many drafts and common issues. AFAIK Brett didn't help 
editing the CPL draft, but he did for the draft-pentland-dna-protocol draft.

    Erik

---

From: James Kempf <[email-masked]>
Date: Tue, 19 Jul 2005 09:35:15 -0700

> been another thorough effort to handle movement.

In fact, AFICT, RFC 2894 has not received a lot of operational testing.

            jak

---

From: Greg Daley <[email-masked]>
Date: Wed, 20 Jul 2005 09:02:50 +1000

Hi Erik,

[cut]
> confused state for a long time (e.g., 30 days with the default RFC 2461 

I think that the problem in DNA comes (primarily) where there's
lingering state in the network: a host or router which hasn't seen
the zero lifetime retraction.

A zero lifetime retraction is a valid mechanism, but intermittently
connected hosts may not receive the notification that the prefix is
no longer connected.

I'd like to sit and think for a little while and determine if there's
a completely safe way to handle knowledge used for CPL (or CompleteRA
etc.) without facing the danger that the prefixes will be classified
as belonging to one link (when in fact they belong to two, from two
different times).

This shouldn't hamper progression of CPL at the moment.

> about using prefixes for DNAs purpose.

That's understandable.  It would be good later to have his and
other operational opinions of how relevant the problem is, and
how the solutions may be impacted by it.

> been another thorough effort to handle movement.

I think that this is the right place to explore the issue then
(if it's a small enough issue).

Do you think we may need a short PS after IETF?

Greg

---

From: Greg Daley <[email-masked]>
Date: Wed, 20 Jul 2005 09:48:45 +1000

Hi James,

> In fact, AFICT, RFC 2894 has not received a lot of operational testing.

I think I know what you mean, although there has been some work
as part of the 6net project:

http://www.6net.org/publications/deliverables/D3.6.2.pdf

I've yet to read it thoroughly but came across it the other day.

Greg.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Jul 2005 21:38:44 -0700

> connected hosts may not receive the notification that the prefix is

Yes, there are issues even with intermittently connected hosts that 
don't move. Such a host might hear a prefix with a preferred lifetime of 
7 days, and then never hear anything more about that prefix, even though 
the prefix might have been announced with a preferred and valid lifetime 
of zero for a while (when the host wasn't connected). There is a fix to 
this (keep announcing the prefix with a lifetime of zero until its 
original "expiration" time passes).
However, such a fix wouldn't help with DNA, since the host might attach 
to a different link and not the same link.

> as belonging to one link (when in fact they belong to two, from two

Let me know if you come up with something.

ok

> Do you think we may need a short PS after IETF?

I'm not sure.

    Erik

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 21 Jul 2005 18:06:26 +0900

Dear Greg

> connected hosts may not receive the notification that the prefix is

Dormant mode also gives a problem. 

For example, assume a link with prefix Prefix1. A node N receives 
a prefix A::, then becomes dormant for a while. Meanwhile Prefix 1 
is removed from the link and moved to the other link. Because
N is in dormant mode, it doesn't know about this. Then N happens 
to move and awake to attach itself to the latter link. Because it sees 
Prefix1, it will falsely assume that it still is at the same link. 

> as belonging to one link (when in fact they belong to two, from two

This is what I devise for linkid scheme. 

To solve "Flash renumbering and and early reassignment, linkid draft 
proposes that, when a linkid prefix is removed from a link, the linkid 
prefix should not be re-assigned to other link in 3 hours. With the 
above, a host would not see the same linkid prefix in two different links 
because linkid lifetime is 1.5 hour.

> This shouldn't hamper progression of CPL at the moment.

Glad to hear that. :-)   

> how the solutions may be impacted by it.

I talked with network operators and found out prefixes are 
rather stable. So my guess is, this will not affect DNA much
except in some very volatile network which I can't  imagine  
right now.  

> Do you think we may need a short PS after IETF?

Both Linkid & Landmark/ CompleteRA deal with this in Open 
Issue. 

For Linkid, there is 

   Issue 003: Flash renumbering and early reassignment

For Landmark/ CompleteRA, there is 

   Issue 0012: Network renumbering - guidelines for deployment

We may mention this problem in open issue presentation. 

Best Regards

JinHyeock

---

From: Greg Daley <[email-masked]>
Date: Fri, 22 Jul 2005 09:02:59 +1000

> Prefix1, it will falsely assume that it still is at the same link. 

Yes, I believe this is the same case as "intermittently connected"
though, as in both cases, the host is not aware of state changes
on the link.

I guess we can collapse these two cases into one.

> because linkid lifetime is 1.5 hour.

This isn't a completely safe solution, since people do strange things
which violate recommendations they haven't read.

I used to work in Tech Support (in another life), so I know things
like this happen.

Existing Router deployers may not read the DNA specifications, so I'd
like to take a step back and see if we can have a sane failure mode
even for less sane changes.

> except in some very volatile network which I can't  imagine  

That's useful to know.

There are a lot of issues in IPv6 which may increase prefix churn
though (for example, if SHIM6 makes it simple to maintain
sessions across renumbering).

Also, we haven't seen wide deployment of DHCPv6 Prefix
Delegation yet.

In PD, as soon as the prefix's valid lifetime has expired it could be
on another link.  I'm not even sure we want to see what happens if
there's state loss on the server (maybe this is a flash renumbering
case).

If we have to plan for address prefix boundaries other than /64,
we may also have to plan for dynamic environments.

> We may mention this problem in open issue presentation. 

That sounde like a fair idea.

Greg

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 22 Jul 2005 13:16:05 +0900

Dear Greg

> I guess we can collapse these two cases into one.

ok. 

> which violate recommendations they haven't read.

I agree. But this is all I can think of right now. Also can there be 
a solution which is completely safe from a human folly? I doubt it. :-)

> even for less sane changes.

Even in case of trouble from a rule violation, the bad effect will go away 
in 1.5 hours, just like the case of CPL.  

But if a better way to deal with this issue is designed, it will be nice. 
 
Thanks in advance for your kind consideration. 

Best Regards

JinHyeock

---

From: Greg Daley <[email-masked]>
Date: Fri, 22 Jul 2005 14:41:19 +1000

Hi JinHyeock.

I'm writing e-mails out-of-order too.

> a solution which is completely safe from a human folly? I doubt it. :-)

Apparently not, if you read the IETF list (people have been
discussing phishing).

> in 1.5 hours, just like the case of CPL.  

I was talking to Brett about this today.

I agree that safety measures like that may be necessary in some
form anyway, and it may make sense to ensure that the DNA
devices take the action to expire bad information.

> But if a better way to deal with this issue is designed, it will be nice. 

As I said before, it shouldn't slow down CPL since it's OK as it
stands, though.

If a bolt of inspiration comes, we'll explore things then.

Greg

---

From: James Kempf <[email-masked]>
Date: Fri, 22 Jul 2005 00:25:49 -0700

> > as belonging to one link (when in fact they belong to two, from two

Like I said during the design team discussions, dormant mode must be handled
separately. When the host drops into dormant mode, it must invalidate any
local link state and start from scratch when it comes out. There is other
local link state that needs to be handled like this, for example
autoconfigured addresses. The node shouldn't have to wake up in order to
defend its address. Hence, there is no point in having it hang onto DNA
state.

Personally, I think we need to spend some time thinking about dormant mode a
little more deeply, rather than trying to bring issues involving dormant
mode up piecemeal in various contexts (it came up recently during the MIPv6
to IPv4 DT discussions too). These peripherial discussions lead to rather
superficial suggestions for solutions, that don't consider the entire
spectrum of what is needed to properly support dormant mode.

Perhaps we need to have a BOF specifically on dormant mode support.

            jak