RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

["Wes Beebee (wbeebee)" <[e-mail]>]

Comments from me between <wb> and </wb> 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Hemant Singh (shemant)
Sent: Thursday, July 03, 2008 4:36 PM
To: Thomas Narten; Brian Haberman
Cc: [e-mail]; Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Thomas,

Thanks for the quick reply and review.  Please see in line below between
"<hs>" and "</hs>". 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Thomas Narten
Sent: Thursday, July 03, 2008 3:25 PM
To: Brian Haberman
Cc: Bob Hinden; [e-mail]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

My. $.02.

Close to ready to ship.

Substantive:

>    In addition to the Prefix List, individual addresses are on-link if
>    they are the target of a Redirect Message indicating on-link, or
the
>    source of a valid Neighbor Solicitation or Neighbor Advertisement
>    message.

Per list discussion, this last part should be dropped.

<hs>Done. I had sent an email today saying the text has been removed.
What was removed is text between quotes below.
 ", or the source of a valid Neighbor Solicitation or Neighbor
Advertisement message."
</hs>

<wb>Note that we also pointed out later on that this is a change from
RFC4861 that is being made in this draft (which updates RFC4861).
</wb>


>    3.  On-link determination SHOULD NOT persist across IPv6 interface
>        initializations.  Note that section 5.7 of [RFC4862] describes
>        the use of stable storage for addresses acquired with stateless
>        address autoconfiguration with a note that the Preferred and
>        Valid Lifetimes must be retained if this approach is used.
>        However no RFC suggests or recommends retaining the on-link
>        prefixes.

Hmm. I agree that the current specs don't suggest doing this, but is it
forbidden or wrong? I.e., is caching on-link information any worse than
caching the generated addresses? The PIO has Lifetime fields, and as
long as they are honored... ANd indeed, that is what point 4
reinforces...

<hs>True, but what if someone has manually configured an IPv6 address
with prefix length, what are the Lifetime values for such a prefix? I am
not sure what happens here. Why not be then explicit and include such a
bullet. Also, the subject of our draft is focused on on-link
determination so we added such a bullet for completeness sake since
RFC4862 mentions persistent data across initializations. It is RFC4861
that deals with on-link determination. So why not have RFC4861 have such
text for on-link determination related to persistent storage. 
</hs>

<wb>
What if there are cache-inconsistency problems, prefix renumbering, or
stale information?  I think it's better just to get rid of caching
on-link information in stable storage and get such information fresh
from RA's.  That way, administrators can better rationalize the behavior
of their network from the configured RA's.
</wb>

I don't see right off why rule 3 is needed.

>    5.  Newer implementations, which are compliant with [RFC4861] MUST
>        adhere to the following rules.  Older implementations, which
are
>        compliant with [RFC2461] but not [RFC4861] may remain as is.
If
>        the Default Router List is empty and there is no other source
of
>        on-link information about any address or prefix:

Hmm. When are we going to say implementations of 2461 should be fixed
and no longer support the "all destinations are on link?". Again, I am
not sure point 5 is appropriate to include here, other than perhaps to
point out that the 2461 behavior is deprecated.

<hs>We'd like to keep this bullet because as you said, we wanted to
point out deprecated behavior. Further host implementations are
sometimes really blind and issue NS for non-link-local address even when
the host has been signaled off-link or host needs to issue only an
ICMPv6 error. We wanted to make such things clear even in this bullet.
It may be better to keep the behavior lock, stock, and barrel in bullet
5. Not only does an ICMPv6 Destination Unreachable need to be issued,
the host cannot issue an NS to resolve a non-link-local destination.
Further folks were also not sure where is the ICMPv6 Destination
Unreachable headed to even after RFC4943 has been published before our
draft? We made it very clear in this bullet 5.
</hs>

<wb>
We need to point out changes in behavior for people still following old
specifications so that they know what they need to change moving
forward.
</wb>

Editorial:

> 1.  Introduction
> 
>    IPv4 implementations associate a netmask when an IPv4 address is
>    assigned to an interface.  That netmask together with the IPv4
>    address designates an on-link prefix.  Addresses that match this
>    prefix are viewed as on-link i.e., traffic to these addresses is 
> not

Better:

   IPv4 implementations typically associate a netmask with an address
   when an IPv4 address is assigned to an interface. That netmask
   together with the IPv4 address designates an on-link prefix.
   Addresses that are covered by this prefix are viewed as on-link
   i.e., traffic to these addresses is not sent to a router.  See
   section 3.3.1 in [RFC1122]. Prior to the deployment of CIDR, an
   address's netmask could be derived directly from the address. In
   the absence of specifying a specific netmask when assigning a
   address, some implementations would fall back to deriving the
   netmask from the class of the address.

<hs>Yes, it is better - thanks! I have no problem with using it. 
    Hopefully Wes and Erik will not disagree with me.
</hs>

<wb>
I'm fine with this too.
</wb>

>    2.  The configuration of an IPv6 address, whether through IPv6
>        stateless address autoconfiguration [RFC4862], DHCPv6
[RFC3315],
>        or manual configuration MUST NOT imply that any prefix is on-
>        link.  A host is explicitly told that prefixes or addresses are
>        on-link through the means specified in [RFC4861].  Note that
this
>        requirement for manually configured addresses is not explicitly
>        mentioned in [RFC4861].
> 


Better (?):

   2.  The configuration of an IPv6 address, whether through IPv6
       stateless address autoconfiguration [RFC4862], DHCPv6
       [RFC3315], or manual configuration MUST NOT implicitely cause a
       prefix derived from that address to be treated as on-link.  A
       host considers a prefix to be on-link only through explicit
       means, such as those specified in [RFC4861] or via manual
       configuration. Note that the requirement for manually
       configured addresses is not explicitly mentioned in [RFC4861].

<hs>Yes, this is better too - thanks again. I have no problem with using
it.

Appreciate the quick review before a long weekend.

Have a good one.

Hemant
</hs>

<wb>I think this needs to be merged with our new text on this one which
points out 
that bullet 4 was explicitly removed from the definition of on-link
which was in 
RFC4861.
</wb>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------