Alexandru Petrescu writes:
> James Carlson wrote:
> > Alexandru Petrescu writes:
> >> While the document does talk about stateless address autoconf I
> >> think it should also talk about ND. I think it should mention
> >> whether - or not - it's possible, feasible, has been done or
> >> probable, to run IPv6 ND over a ppp link.
> >
> > It's being done today. RFC 2461 specifies that ND is supposed to be
> > run on point-to-point links.
>
> Yes, it does. But not clear whether peer sends NS to the other peer or
> not; or whether peer sends NA or not. Why would it if there's no
> link-layer address.
I can think of at least one reason: it allows you to minimize the
differences between the operation on point-to-point links and on other
types of links.
For instance, you can still do all the odd things you'd ordinarily do
with the 'R' bit in the NA.
> Not clear what a NC entry looks like when there's no link-layer address.
It has no link-layer address.
> Not sure what a link-local multicast address looks like over a
> point-to-point link: still ff02::1 and ff02::2 (link local)?
Sure.
> Or ff01::1
> and ff01::2 (interface local - since both interfaces are tightly connected)?
No. ff01 means same node in IPv6ish.
> Not sure the solicited-node address (FF02:0:0:0:0:1:FFXX:XXXX) does
> still use the last 24 bits of the Interface ID derived by IPv6CP.
Why would it not? I don't understand why we would want to invent
special cases where none need exist.
> Not sure whether an anycast IID can or shouldn't be negotiated by
> IPv6CP. If the peer is a router it must use a subnet-router 64-0bits
> anycast ID on an interface (rfc4291), but ConfigReq with a 0 InterfaceID
> is sign of negotiation initiation, not conclusion.
I don't see what that has to do with IPV6CP.
I assume you're talking about RFC 4291 section 2.6.1. That address is
constructed in exactly the same manner if PPP links are in use, and
has nothing whatsoever to do with the IPV6CP Interface ID option. The
PPP negotiation is used for the IPv6 link-local address construction.
You don't (and should _not_) be trying to negotiate those bits used in
the construction of that anycast ID.
> Not sure about an 'anycast ID' rfc2526, which is on 7bits and is part of
> the IID, and is same on both peers. That RFC also says no IID should
> ever contain the first 54bits all-ones, so IPv6CP negotation should at
> least ensure it never negotiates IIDs whose leftmost 54bits are all ones.
That seems likely to me; I think the authors of RFC 2526 ought to take
this one up, as it's a result of the way this document carves out
space for these special addresses.
> Maybe all of these are out of scope when ND runs over a point to point link?
No ... but I'm not sure that all of these issues are relevant to the
IPV6CP draft.
> > Note that it says "link layers that have addresses." Point to point
> > interfaces don't have addresses, and thus ND messages on PPP links
> > shouldn't include the SLLA/TLLA options.
>
> Sounds logic.
>
> To me STLLAOptions carried in ND messages is a good means to have easy
> ND when there's no link-layer header to carry link-layer addresses.
That sounds like a proposed revision of 2461. I'm not sure why it's
needed, but I'm pretty sure it's out of scope for IPV6CP.
> > In that case, there'd just be one address on the link for the given
> > prefix. If there's only one address, you can't possibly have a
> > conflict.
>
> So one would have to prohibit the manual ('administrative') assignment
> of that address on the interface too, not just the 'autoconfiguration'
> assignment of that address. A router doesn't autoconfigure an address
> based on the RA it sends, neither based on an RA it receives.
Yes.
> Also, a router must assign a subnet-router anycast address (rfc4291) on
> the routing interface, that is a prefix::0/128 address; so at least that
> address must be assigned on the interface.
Yes, but because it uses all-zeros, it can't possibly conflict with
any IPV6CP interface identifier.
> > A PPP link may or may not represent a link to a router with
> > sufficient connectivity to be a useful "default router." The only
> > way you know is if that router tells you so.
>
> Ok.
>
> We don't want both of them to be routers and advertise themselves as
> default routers either.
I don't see how we can dictate that people deploy their networks
sanely. The protocols must work even if the people are silly.
In the case that both are routers, they'll both process the RAs
according to the existing RFCs. This means that neither will treat
the other as a default, no matter _what_ the RA says. Presumably, if
they're both routers, then both are running _real_ routing protocols
(such as OSPF) rather than ersatz ones like Router Discovery.
If neither is a router, then you just have a plain old IPv6 link
between two nodes.
I don't see a conflict here.
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
