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.
> If yes, then the SLLAO/TLLAO options (source link-layer
> address option, and target) could be encoded from the Interface IDs
> derived by IPv6CP. And if we talk link-local IPv6 multicast addresses
> on the ppp links then also we can have a meaningful way to describe them.
PPP links don't have layer two addresses; they're point-to-point.
I don't think I agree that these options ought to be used to convey
the PPP Interface ID values. RFC 2461 says this:
Source link-layer address
The link-layer address of the sender, if known.
MUST NOT be included if the Source Address is the
unspecified address. Otherwise it SHOULD be
included on link layers that have addresses.
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.
> > 2) The access router terminating the PPP link does not autoconfigure
> > any IPv6 global unicast addresses from the prefixes that it
> > advertises.
>
> Not sure I understand the 2nd condition here. Is it that we don't want
> the AR to _statelessly autoconfigure_ (a router never does anyways) or
> that we don't want the AR to have an address in same prefix as the host?
> How would absence of global address on AR help avoiding DAD?
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.
> I also think since ppp is used to connect to an Access Router that that
> AR should be a default router, i.e. we can state it in terms of ND RA
> lifetimes.
?
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.
> Still in the section stateless autoconfig, it would be worth mentioning
> whether the initial RA is sent to all-nodes link-local address, or to
> the link-local address that the PPP server delivered to the host.
I believe that you can do either, and that both should (must) work.
For what it's worth, PPP isn't client-server -- it's peer-to-peer.
One end of the link isn't necessarily privileged in any manner, though
in some particular usages (deployments) this is so.
> Finally, there are ppp implementations that don't negotiate the IID with
> the server (non compliant with this spec) but who'll still print a
> link-local IPv6 address, fe80::something. That "something" is always
> the same, on all hosts here or in Australia, and it's not 0. It allows
> the IPv6 stack so still somehow work even if the PPP peer is not IPv6
> capable and if this spec isn't used. If you think it's worth talking
> about this non-compliant IPv6 ppp interface then I could dig the form of
> that 'something'.
In my opinion, this is actually compliant with RFC 2472 and with the
update. If you can't come up with a unique interface identifier,
you're permitted to use another source, such as static configuration:
Default
If no valid interface identifier can be successfully
negotiated, no default Interface-Identifier value should be
assumed. The procedures for recovering from such a case are
unspecified. One approach is to manually configure the
interface identifier of the interface.
It probably _shouldn't_ do that, and yelling at the vendor might help,
but I don't think it's inherently wrong. (I don't see how it helps at
all if the peer doesn't know IPv6 -- there's no way a non-IPv6-capable
IP node can forward IPv6 datagrams, is there?)
--
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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
