[AusNOG] So who's read an RFC or Internet Draft?

[Mark Smith]

Hi Geoff,

On 7 October 2015 at 06:42, Geoff Huston <gih at apnic.net> wrote:
>> "Addresses
>>
>>    Addresses are variable length strings of 4 bit chunks prefixed by a
>>    length.  As address chunks are processed they are removed from their
>>    position at the head of the address chunk string and placed at the
>>    end of the string.  This chunk by chunk circular shifting of the
>>    address allows each node in the hop by hop processing of a message
>>    to examine the part of the address it consumes with out knowing how
>>    much address preceeds or follows that part."
>>
>> It is also interesting as there were no source address in the
>> "internet protocol message”!
>
>
>
> Yes, at one point IP played with the concept of variable length addresses,
> which also appeared later in the OSI NSAP address structure, as I recall.
>

Yes, OSI NSAPs are variable length. Going by what Christian Huitema
said in his "IPv6: The New Internet Protocol" book, one of the reasons
for fixed length IPv6 addresses was that even though OSI NSAPs could
be variable length, people opted for the simplicity of using the same
OSI NSAP length anyway. I think most humans tend towards simplicity if
they can (a.k.a. laziness).

> There is a story here I was told by Jon about the involvement of a gentleman from
> Digital in the who was adamant that Digital’s equipment could not process
> variable length addresses at wire speed and he pushed hard for fixed
> boundaries in the packet. The compromise was 32 bits fixed size addresses.
>
> (The same argument resurfaced in the IPv6 chained extensions header structure.
> What goes around come around!)
>

(following for the general AusNOG audience, I'm sure I don't need to
tell you how to suck eggs :-) )

I think one of the fundamental questions to ask or consider is where
the specific packet fields are intended to be processed - in the
network somewhere, or at the ends/hosts?

I think the Internet is scaled by pushing complexity to or towards the
edge i.e., into the hosts. I think that is a form of solving a problem
using the "divide-and-conquer" approach, or horizontal rather than
vertical scaling. Pushing complexity to the edge means processing in
the network is and should be kept as simple as possible. I think that
is then the argument for simpler fixed length fields, such as
addresses, rather than variable length ones in fields that are to be
processed by the network. Vertical scaling (e.g., buying a bigger
router or link), if there is no choice to scale horizontally, is
either easier, or just actually able to be achieved, if the thing
being vertically scaled is simple rather than complex.

Only one of the IPv6 EH's is intended to be processed in the network -
the Hop-by-Hop EH - and that is why it is required to be directly
after the IPv6 header. The rest are to be processed by the end or host
destination of the packet, which means that other than the HBH EH, all
the other EHs are "end" fields rather than "network" fields. EH
processing in the network at high speed may be costly, hard and/or
impossible. Even HBHs are in some cases being punted to software
processing in the control plane of routers, and that can make the
control plane vulnerable to a denial of service attack, so in some
cases packets with HBHs are being intentionally dropped rather than
punted to software by some networks.

> At the _IP layer_ who needs source? I’ve forgotten who pushed for the
> source to be added to the IP packet, if I ever knew, but in IPv4 the model
> was that the IP information state was forward, and nothing was meant to head
> backward, so the source address was unnecessary.
>
> (You could argue that IPv6 PTB treatment is a basic violation of this
> ‘forward flow’ principle, and you could well be correct!)
>

I think for pure destination based delivery, certainly you're right.
Having source addresses in packets certainly helps with
troubleshooting though!

It is a while since I looked into it, however it is my understanding
that the IEEE dropped carrying of source addresses in 802.11 frames
(i.e., IIRC, those under the 802.3 frames) because technically they're
not needed, as all traffic is (or was) either between a station and an
access point, so each receiving device inherently knows what device
sent the frame, because there is no ambiguity - it is a point-to-point
link. However, since then the IEEE have had to define a "4 address
format" mechanism, which puts source addresses back in frames, so that
things such as wifi bridges could be built. Dropping the source
addresses may have saved half a dozen bytes in a frame, but it has now
created compatibility issues.

So it is probably better to always include a source address in frames
or packets regardless for troubleshooting and possible other
unforeseeable future reasons.


>> So Internet addressing evolved a lot before we ended up with the IPv4
>> addressing we have today. It is worth remembering that Vint Cerf, Bob
>> Kahn and many others (excepting Jon Postel (RFC2468) and a few others)
>> are still around, and having had the above experiences, I think the
>> rest of us can be fairly confident that IPv6's 128 bit address size is
>> going to be adequate.
>>
>
>
> really?
>
> http://www.potaroo.net/presentations/2005-04-19-v6.pdf
>

Thanks for that, I'll have a look.


Regards,
Mark.

>
> Geoff
>
>