[v6ops] Seems AERO / RFC6706 is the subject (Was: Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4)

[Jeroen Massar <[e-mail]>]

On 2014-11-03 17:21, Templin, Fred L wrote:
> Hi Jeroen,

So it seems we strayed somewhere off the '6to4 replacement' subject and
got into a discussion about AERO / RFC6706. Apologies that I did not
notice that context switch. Updated the Subject: to match this.


>> -----Original Message-----
>> From: Jeroen Massar [mailto:[e-mail]]
>> Sent: Sunday, November 02, 2014 10:43 PM
>> To: Templin, Fred L
>> Cc: [e-mail] WG
>> Subject: Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4
>>
>> On 2014-11-02 22:21, Templin, Fred L wrote:
>>> Hi Jeroen,
>>>
>>> You seem to be getting wrapped up with the notion that I am wanting DHCPv6 to maintain
>>> lots of unnecessary state. I don't - I am primarily interested in the DHCPv6 signaling messages
>>> themselves and their implication for the NBMA interface neighbor cache:
>>
>> For the subject at hand:
>>  "getting IPv6 to endsites that do not have it yet"
>>
>> You do not need anything DHCP-ish. DHCP is for directly-on-the-same-link
>> endpoints.
> 
> For the NBMA tunnel virtual interface I am describing, all endpoints are
> directly-on-the-same-link, and DHCPv6 clients and servers are always
> single-hop neighbors.

If you indeed have a such a virtual network already setup, then as it is
multi-access doing DHCP makes sense.

The problem is that you first need to set up such an (overlay) network
and inform all involved who are involved.

[..]
>> And you need a tunnel before being able to do anything DHCP-ish.
> 
> The NBMA tunnel interface is always available, and can be used to send an
> encapsulated packet to any prospective neighbor at any time and with no
> explicit configuration. Brian Carpenter knows this. He invented it.

As Brian has a very large curriculum, which one do you mean?

Encapsulating things does not mean that those packets make it to the
other side. proto-41 for instance does not go through NATs.

Something has to set it up, something has to configure it.

>> Unless you propose people start dropping those
>> DHCP firewall rules around the Internet (yes, people block DHCP there
>> for obvious reasons).
> 
> It would not look like DHCP on the physical links that carry the tunneled packets;
> it would all just look like UDP port 8060.

Aha, it seems you are talking about experimental RFC6706.

The only reference in that document to using the port is the "AERO
Redirection Message Format", thus I can only assume that something else
has to carry the actual packets and those packets are not likely going
to go over the 8060/udp port you mention.


Something has to tell the involved hosts where and how to send those
packets though, there is no magic specified in that RFC that will tell
otherwise. Those parameters are part of your tunnel setup.

And even if those special "AERO" packets are inside UDP, where are the
real packets going to be encapsulated in?

>> TSP or TIC (pick your poison) already solve the "signaling" for figuring
>> out the tunnel parameters. Then use 6in4(-heartbeat)/TSP/AYIYA to
>> actually get the tunnel going.
> 
> There is no need to get an NBMA tunnel going; it is always going, and always
> available to send tunneled packets to any prospective neighbor.

Something has to configure it; after that, yes, likely that it will keep
on working. Though NATs have these nasty timers that this magic NBMA
tunnel has to account for and keep alive (simply keeping on sending
packets typically does the trick though, but one has to account for the
source port on the NAT side changing over time and that typically this
only works for UDP).

>> No need to come up with new protocols that make things more complex than
>> that.
> 
> You are inferring complexity where there is none. Any Client can send a
> Server an encapsulated DHCPv6 or IPv6 ND packet at any time and with
> no explicit tunnel configuration. And, it is really not a new protocol; it
> is based on long-standing Internet standards.

That can only work when you have that virtual overlay that can do
multicast style setups.

It will be grossly inefficient to that on a scale of 10.000 clients
where only 2 (the server and that specific client) need to see that packet.

As such not appropriate for a system the scale that should 'replace' 6to4.

>> TSP (the signaling/configuration part) is already XML based for
>> 'extensibility'.
>>
>> Note that TIC was developed in parallel and chose a simple SMTP-alike
>> protocol; though if I would have to do it now I would simply use HTTP as
>> that has a lot less issues with firewalls.
> 
> AERO uses IPv6 ND and DHCPv6 the same as for any link.
> This takes care of neighbor discovery

Why does a tunnel need Neighbor Discovery? Unless you are stuffing every
client in the world on the same /64. The endpoints likely already know
what the other end is anyway.

> mobility management

Mobility of what kind? There is all kinds of mobility.

Some people still think that IPv6 Mobility is an actual thing that
exists and gets used. I have actually never seen anybody use it... KAME
MIP6 etc are there but rarely actually get used except for
playing/testing. http://www.mobileip.jp/ is even missing in action...

> multihoming,

Single homing right? There is no "Send packets here first" or "send 50%
of the packets here" or "I am also at" messages in AERO from what I can see.

Hence, even if we just look at the redirect, the packet will go to one
place. Maybe you mean that the underlying carrier handles this?

Proper multihoming has a lot of factors, amongst which available
bandwidth per endpoint, latency properties etc. None of which are easily
figured out and most of which are easily misguessed/configured.

Hence why most multihoming setups typically monitor the availability of
a link and then just hot-potato packets over each link, stopping to send
when that link is 'full' or does not respond in an expected way.
Or by selecting based on QOS or specific destinations. BGP/OSPF etc come
into play a lot there.

> link-local address autoconfiguration,

The link-protocol (Ethernet or other tunnel mechanism) should take care
of that. Thus all link types that require it will do that. How is this a
special feature?


> prefix delegation and anything you might want to do on
> an ordinary IPv6 link with one exception - the AERO link is link-local-only.

Why would it only be link local?


Anyway, my apologies for not reading into your messages that you where
talking about RFC6706. More apologies for not knowing that it was a
draft and was going for RFC otherwise I could have read and reviewed it
and asked various questions about it.

For me RFC6706 is a long piece of text with a lot of claims and
complexity, but it does not actually state what is actually happening.

>From reading it my summary is:
 - AERO defines a 'redirect' message to 'repoint a tunnel endpoint'
   (section 6.4.5)
 - some tunneling protocol is used to carry actual packets.
 - not defined how these tunnels are configured

As such, for me that whole RFC is unclear what the target is, or more
importantly what problem it is supposed to solve in the first place.
(yes, there are requirements, but these seem to be written around what
the protocol does, not what actual problems there are in the world)

And thus I also wonder how that got into this thread about a 6to4
replacement: problem = get IPv6 to endhosts that do not have it.

But then again, I might just be missing something completely obvious...

Greets,
 Jeroen