[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: RE: <draft-ietf-6man-rfc4291bis-09.txt>
From: Mark Smith <markzzzsmith () gmail ! com>
Date: 2017-08-05 0:19:57
Message-ID: CAO42Z2xkYwuS0DafzKBnHoWr2RzLEfgC1uadpa4dYOjWeT4vXw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 25 Jul. 2017 06:18, "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
wrote:
From: David Farmer [mailto:farmer@umn.edu]
> What? Yes it says they are 64bits, but it is just referencing RFC 3513,
> which is what I would expect it to do, which is the predecessor of RFC
4291.
Agreed. These two RFCs do not differ, in regards to requiring 64 bits,
*and* EUI-64 in particular.
> If you think RFC 4291 is really saying SLAAC IIDs are 64 bits then so is
> RFC 3513 and RFC 4193 too.
No, RFC 4291 is agnostic on SLAAC IID length. It refers the reader to
whatever IPv6-over-foo RFC, for IID length and formulation. But RFC 4193
(ULA) seems more insistent that it must be 64 bits and EUI-64. After all,
as specific as RFC 4193 is on how to create ULA prefixes, there's no other
option than 64-bit IIDs, for ULAs.
What I am saying is that 6man seems to have come to an agreement that SLAAC
should be restricted to using 64-bit IIDs.
This SLAAC restriction is not directly related to RFCs 2464, 4291, or 4862,
because these all mandated EUI-64. Still, we seem to want 64-bit IIDs
mandatory for SLAAC. Why? Because we want 64-bit IIDs to be the "default"
and "recommended" length, and because we figure that SLAAC will be the most
popular way of forming IPv6 addresses.
So, if RFC 4291-bis wants to state as much, that's okay with me.
I think the IID length rules can be considerably simplified, compared with
the "exceptions" listed in RFC 4291. Instead of "exceptions" to the 64-bit
hard boundary, list the cases where it applies. SLAAC mostly, maybe a
mention of Ethernet LLAs (although subject to update of RFC 2464), and
ULAs. Just trying to be consistent here.
Look at RFC8064, the list of Foo-over- IPv6 RFCs that it updates all
generate 64 bit IIDs.
We simplify in computing by generalising and by reducing or avoiding
exceptions. Simplicity makes things more robust, as there is less
opportunity for faults to occur (e.g., coding bugs, misconfiguration,
unexpected function or system interaction).
Tying IID size to specific link layers or specific address configuration
methods is increasing complexity, not reducing it. What justifies this
increased complexity? I don't think "because that's how IPv4 worked" does.
IPv4 is complex (e.g. classes, subnets) because there weren't enough
addressing bits.
(People may not be aware, the first IPv4 address structure was a simple
N.H.H.H format. Classes were introduced between RFC760 and RFC791 because
they were going to run out of network numbers and couldn't increase the
size of the IPv4 address.)
Regards,
Mark.
Bert
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[Attachment #5 (text/html)]
<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On 25 \
Jul. 2017 06:18, "Manfredi, Albert E" <<a \
href="mailto:albert.e.manfredi@boeing.com">albert.e.manfredi@boeing.com</a>> \
wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">From: David Farmer [mailto:<a \
href="mailto:farmer@umn.edu">farmer@umn.edu</a>]<br> <div class="quoted-text"><br>
> What? Yes it says they are 64bits, but it is just referencing RFC 3513,<br>
> which is what I would expect it to do, which is the predecessor of RFC 4291.<br>
<br>
</div>Agreed. These two RFCs do not differ, in regards to requiring 64 bits, *and* \
EUI-64 in particular.<br> <div class="quoted-text"><br>
> If you think RFC 4291 is really saying SLAAC IIDs are 64 bits then so is<br>
> RFC 3513 and RFC 4193 too.<br>
<br>
</div>No, RFC 4291 is agnostic on SLAAC IID length. It refers the reader to whatever \
IPv6-over-foo RFC, for IID length and formulation. But RFC 4193 (ULA) seems more \
insistent that it must be 64 bits and EUI-64. After all, as specific as RFC 4193 is \
on how to create ULA prefixes, there's no other option than 64-bit IIDs, for \
ULAs.<br> <br>
What I am saying is that 6man seems to have come to an agreement that SLAAC should be \
restricted to using 64-bit IIDs.<br> <br>
This SLAAC restriction is not directly related to RFCs 2464, 4291, or 4862, because \
these all mandated EUI-64. Still, we seem to want 64-bit IIDs mandatory for SLAAC. \
Why? Because we want 64-bit IIDs to be the "default" and \
"recommended" length, and because we figure that SLAAC will be the most \
popular way of forming IPv6 addresses.<br> <br>
So, if RFC 4291-bis wants to state as much, that's okay with me.<br>
<br>
I think the IID length rules can be considerably simplified, compared with the \
"exceptions" listed in RFC 4291. Instead of "exceptions" to the \
64-bit hard boundary, list the cases where it applies. SLAAC mostly, maybe a mention \
of Ethernet LLAs (although subject to update of RFC 2464), and ULAs. Just trying to \
be consistent here.<br></blockquote></div></div></div><div dir="auto"><br></div><div \
dir="auto">Look at RFC8064, the list of Foo-over- IPv6 RFCs that it updates all \
generate 64 bit IIDs. </div><div dir="auto"><br></div><div dir="auto">We simplify in \
computing by generalising and by reducing or avoiding exceptions. Simplicity makes \
things more robust, as there is less opportunity for faults to occur (e.g., coding \
bugs, misconfiguration, unexpected function or system interaction).</div><div \
dir="auto"><br></div><div dir="auto">Tying IID size to specific link layers or \
specific address configuration methods is increasing complexity, not reducing it. \
What justifies this increased complexity? I don't think "because that's \
how IPv4 worked" does. IPv4 is complex (e.g. classes, subnets) because there \
weren't enough addressing bits.</div><div dir="auto"><br></div><div \
dir="auto">(People may not be aware, the first IPv4 address structure was a simple \
N.H.H.H format. Classes were introduced between RFC760 and RFC791 because they were \
going to run out of network numbers and couldn't increase the size of the IPv4 \
address.)</div><div dir="auto"><br></div><div dir="auto"><br></div><div \
dir="auto">Regards,</div><div dir="auto">Mark.</div><div dir="auto"><br></div><div \
dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div \
class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="elided-text"><br>
Bert<br>
<br>
------------------------------<wbr>------------------------------<wbr>--------<br>
IETF IPv6 working group mailing list<br>
<a href="mailto:ipv6@ietf.org">ipv6@ietf.org</a><br>
Administrative Requests: <a href="https://www.ietf.org/mailman/listinfo/ipv6" \
rel="noreferrer" target="_blank">https://www.ietf.org/mailman/<wbr>listinfo/ipv6</a><br>
------------------------------<wbr>------------------------------<wbr>--------<br>
</div></blockquote></div><br></div></div></div>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic