There's an individual contribution here that proposes to extend LCP
for Mobile IPv6:
http://www.ietf.org/internet-drafts/draft-park-pppext-mip6-co-00.txt
I can't tell, but I assume that the author is intending to propose
this for publication as some form of RFC (Informational?). I don't
think that this should be published as an RFC in its current form.
There seem to be a number of problems here.
The draft makes this assertion, which seems to underpin the entire
rationale for the new configuration option:
> When Mobile-IPv6 is implemented on top of PPP, the time elapsed in
> configuring IPv6 addresses is crucial consideration.
The problem with this is that the draft seems to provide no actual
analysis of the cost of the current scheme, nor does it explain why
this is the best of the alternative solutions.
The draft proposes to place network-layer-specific negotiation into
LCP. This doesn't seem right to me. There's no link authentication
done at the point that LCP operates, so there's no reliable way to
know what node is connecting, or whether that node will run IPv6 at
all, and thus no good way to assign network resources. The fact that
network-layer configuration information is being transmitted and
accepted before any authenticatio is done should perhaps be included
in the security considerations section.
In addition, LCP is sometimes negotiated by an access server that
knows nothing about the network-layer requirements of the system, as
with L2TP tunneling. In this case, LCP cannot issue this message.
The implementation is restricted to cases where LCP has intimate
knowledge of the network layers in use.
> Subtype = 1, the Value field contains prefix of PDSN. Configure
> Option with Subtype = 1 is transmitted only by PDSN included in
> Configure-Ack.
The draft is less than clear about the operation of this new option,
but I suspect that the text above is in direct conflict with RFC 1661
section 5.2:
On reception of a Configure-Ack, the Identifier field MUST match
that of the last transmitted Configure-Request. Additionally, the
Configuration Options in a Configure-Ack MUST exactly match those
of the last transmitted Configure-Request. Invalid packets are
silently discarded.
As I read this proposal, the new configuration option is included only
in LCP Configure-Ack messages, and isn't negotiated. This appears to
break the requirement from RFC 1661 that the Configure-Ack message
contains only the options found in the most recent Configure-Request,
and no others.
What's really unclear here is why this option is needed. It seems
that it's intended to avoid a single round-trip-time on the link in
the case where MN chooses an IPv6 interface identifier and the PDSN
wants to tell it to use a different identifier.
Why is a single round-trip time important? Are there really links
where this round-trip time is significant compared to any network
layer traffic that might flow on the link?
Is this perhaps papering over implementation flaws, such as an
inability to buffer datagrams when the link is down or (maybe)
triggering retransmit at opportune times?
Why is it not sufficient to have the MN remember the last identifier
it used and try the same one again?
--
James Carlson, IP Systems Group <james.d.carlson@xxxxxxx>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
_______________________________________________
Pppext mailing list
Pppext@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/pppext
|
