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).
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.
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.
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.
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.
Alex
Alexandru Petrescu a écrit :
JINMEI Tatuya / 神明達哉 a écrit :
At Wed, 18 Feb 2009 21:54:37 +0100, Alexandru Petrescu
<[email protected]> wrote:
- prefix P::/56 with L=1, A=0, and - prefix P::/64 with L=0,
A=1
if the receiving host is fully compliant with RFC4861 and 4862.
Excuse my ignorance but I don't see why putting two prefixes in
the RA when one is sufficient with A=1 and L=1.
Because the specification is written that way. From a pure
technical point of view, we could have introduced a new rule, e.g.,
"if the length of a prefix with A=1 is less than 128 - length of
IID, the host should continue configuring an address with the
prefix and the IID, filling in the remaining bits with 0".
Technically that may sound absolutely wonderful, but I agree maybe
more motivation is needed.
My whole point is that it's not worth the time and process overhead
to consider introducing such an additional extension at this stage
without a strong reason, and 'we could do it, why not' is (IMO)
way too weak a reason.
Well, I agree. This is not because we could do it.
Were it said a RA prefix for Ethernet SLAAC could be shorter than
/64, there could be some advantages for: administrative headaches,
saving wireless bandwidth, easier DHCPv6 PD, avoid prefix-per-host
address waste, motivate design of shared multicast-capable links (on
which ND and others depend so largely), replace some proxy ND bridges
with routers, and maybe more.
Alex
--------------------------------------------------------------------
IETF IPv6 working group mailing list [email protected] Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
