On Fri, Feb 17, 2017 at 08:44:20AM +0100, otroan@xxxxxxxxxxxxx wrote:
> 4291:
> For all unicast addresses, except those that start with the binary
> value 000, Interface IDs are required to be 64 bits long and to be
> constructed in Modified EUI-64 format.
>
> 4291bis:
> IPv6 unicast routing is based on prefixes of any valid length up to
> 128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes
> on inter-router point-to-point links. However, the Interface ID of
> all unicast addresses, except those that start with the binary
> value 000, is required to be 64 bits long. The rationale for the
> 64 bit boundary in IPv6 addresses can be found in [RFC7421]
>
> Proposal:
> IPv6 unicast routing is based on prefixes of any valid length up to
> 128 bits [BCP198]. However, as explained in [RFC7421], the
> Interface ID of unicast addresses is generally required to be 64
> bits in length, with exceptions only provided in special cases
> where expressly recognised in IETF standards track documents.
wow, the last sentence of that proposal is overreaching! The text in
4291bis -07 is not ideal either. At this point, I do not believe
rfc4291bis can advance with such text. The contention around unicast
addresses not starting with a binary value 000 must be resolved.
Let's look at the following:
job@tardis:~$ sudo ip -6 addr show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:728:1808:1::21/126 scope global
valid_lft forever preferred_lft forever
inet6 fe80::20d:b9ff:fe41:d4f5/64 scope link
valid_lft forever preferred_lft forever
job@tardis:~$ echo HERESY\! a /126\!
Is the IPv6 Addressing Architecture Police (IAAP) gonna come to crack
down on this? What's IETF going to do about this? Nothing! Is this bad?
No. Should there be any tolerance for "IPv6 capable" hw/sw which can't
cope with a /126, /120 or whatever? No.
The main issue for me on this point is that from a pragmatic point of
view, a architecture policy specification should strive to match the
expected deployment reality. I think we can argue that there now is
sufficient deployment experience to admit that all possible IPv6 prefix
lengths are configured.
Referencing RFC7421 is fine, but please realise that in doing so we're
(by proxy) referencing FDDI, ATM, Token Ring and other fascinating
standards from the good ole' days - imho a 7421 ref is just scrambling
for arguments.
Persisting with a 64-bit boundry fixation is actually making the IPv6
address architecture _less_ expressive. When expressiveness is limited
through an arbitrary rule... that's just shortsighted.
Nobody can claim that we know all use cases (with their respective up
and downsides). However, the few use cases we _do_ know about arrived at
different prefix lengths. Why continue to document exceptions? That is
just busywork. There is no 'one true subnet size'.
Mandating something arbitrary like 'address ID must be 64 bits' when
there is no technical requirement for such rule would be nothing short
of arrogant.
The ND/SLAAC attack vector was real problem, can still be real, why
pretend that that issue doesn't exist by mandating 64-bit IIDs? Any sane
deployment will take steps to cover that risk surface. A valid
mitigation strategy remains to just configure something longer then a
/64 ... like /120
We must accept that we cannot see into the future. Let operators choose.
Kind regards,
Job
ps. The "Write a draft" argument is weak at best, since we are already
are discussing a draft (called 'draft-ietf-6man-rfc4291bis-07.txt'),
which is in IETF Last call, which means it is in a place to discuss the
contents of that draft. No reason to kick the can down the road.