JINMEI Tatuya / 神明達哉 a écrit :
At Thu, 19 Feb 2009 00:15:48 +0100, Alexandru Petrescu
<alexandru.petre...@gmail.com> wrote:
Following up my own post, detailing what I meant, and limiting my
email sending rate right after :-)
Saving wireless bandwidth: allow to send only one PIO in the RA
instead of two. This may be useful for links with limited
bandwidth which imitate the Ethernet API. (e.g. 802.15.4, 802.16).
Yes, this is certainly a waste. The problem is how common this type
of configuration is, especially for such highly bandwidth sensitive
environments. And the next question is whether it's serious enough
to warrant an update to the standard. Personally, I'm not yet
convinced on that point.
I think this unique point does not warrant a modification. The grouping
of all these points may.
Avoid administrator headaches: allow putting only one Prefix/Length
in the config file, instead of two.
Avoid need for bridges and proxy ND: avoid the misunderstanding
whereby users try to build bridges (Proxy ND) instead of real
routers.
My above question also applies here. Plus, IMO I believe this can be
well handled in implementations.
Subnet power to the user: avoid IPv6 provider to take the /64 SLAAC
Ethernet limit as enough for many. Provider could thus offer
users a /63 allowing her/him to further subnet.
I don't understand the logic here, especially about how this leads to
loosen the restriction of 'len(prefix) + len(IID) must be 128'.
Of course, to losen it on the lower side - it must be lower than or
equal to 128.
For ADSL. If operator knows a /56 can be used to SLAAC an Ethernet
interface then operator can deliver a /56 to end user. Operator is also
forced to implement DHCPv6 PD Server in the ADSL box.
In current state: operators can't really evaluate what a user needs.
Operator makes a safe bet; operator assumes that user needs the /64
becuase user certainly has Ethernet devices and, knowing Ethernet SLAAC
can only be /64, operator delivers a /64 to end user. And is freed from
implementing DHCPv6 PD.
DHCPv6 PD power: allow a Prefix Delegation scheme to re-delegate
further (a /56 out of a /52 out of a /48) without each router
needing to reserve a /64 for its own links.
Again, I don't understand it.
If what you mean is something like this:
- router A advertises P::/48 with L=1, A=1
- router B (a downstream of A) advertises P::/52 with L=1, A=1
- router C (a downstream of B) advertises P::/56 with L=1, A=1
while allowing hosts to configure addresses with the shorter prefixes,
then hosts won't be able to communicate off-link: host X, which
receives an RA from router C and configures P::x, would tries neighbor
discovery to send packet to a different host Y, which receives an RA
from router A and configure P::y, because P::y is covered by X's
on-link prefix, P::/56. This attempt will of course fail.
Thanks for digesting an example. I suppose the illustration is:
48 52 56
--A----B----C---
| |
Y X
You seem to say that if RA /56 A=L=1 for X, and /48 for Y, and if X
wants to send a packet to Y (having never sent it a packet before) - it
will fail. However, if X and Y were autoconfigured with /64 prefixes
then it would work; if Iunderstand you correctly.
Avoid prefix-per-host address waste: were it known a /56 could be
used to SLAAC an Ethernet interface - it would be very hard to
claim there are enough /56 prefixes to accomodate one for each
mobile. Or, that is the situation today with /64 (RFC IPv6
cellular, RFC Proxy Mobile IPv6), a situation which - if put in
practice - effectively leads to address waste. Avoiding
prefix-per-host could also lead to designing shared
multicast-capable link layers (for 802.16, 802.15.4), on which ND
and other IPv6 protocols depend so largely.
I'm with Brian here. With all due respect, this sounds like a
hairsplitting to justify the new rule of allowing address
configuration with a shorter length prefix.
I'm generally tempted to silently agree with Brian. But on this
particular point I think I'll stick to the waste aspect - waste is not
good regardless of the space size.
If you have a real world problem that can only be solved by such a
new rule,
Certainly I'm not saying this out of the blue.
I've cited a number of IETF documents which I believe could have been
written differently were that /64 SLAAC Ethernet limitation disappear.
please go ahead writing a draft with detailing the problem and
explaining why the new rule is inevitable. I don't think continuing
the hypothetical argument here will lead us to anywhere constructive.
Well thank you for the invitation. I will leave it here, no draft for
the moment. The implementation details and test you propose can only be
checked later, it takes ages to have this back up.
Alex
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
