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

["Templin, Fred L" <[e-mail]>]

Hi Jeroen,

> -----Original Message-----
> From: Jeroen Massar [mailto:[e-mail]]
> Sent: Monday, November 03, 2014 9:22 AM
> To: Templin, Fred L
> Cc: [e-mail] WG
> Subject: Seems AERO / RFC6706 is the subject (Was: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4)
> 
> 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.

The correct reference for this discussion is 'draft-templin-aerolink', which will obsolete
RFC6706 when it is published. RFC6706 can even now be considered as historic even
though it has not been officially designated as such.

However, 'draft-templin-aerolink' is also a candidate replacement for 6to4. AERO
works everywhere AFAICT, and does more than just a transition mechanism would.
It is in fact intended as a long-term solution which has IPv6/IPv4 coexistence as just
one aspect. Mobility, multi-homing, route optimization, security, etc. are just a few
of the other aspects.
 
> >> -----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.

There is no setup needed. It is tunneling without explicit tunnels.

> [..]
> >> 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?

RFC2529 (circa 1999).

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

AERO can work over proto-41, but the normal case is to use UDP port 8060.

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

It is a tunnel without explicit tunnel configuration.

> >> 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.

No; I am talking about 'draft-templin-aerolink'. UDP port 8060 is shared between
RFC6706 and 'draft-templin-aerolink'.

> 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.

We are out of context; the correct reference for this discussion is
'draft-templin-aerolink'. Although they are much appreciated, I don't think
it would be helpful to try to respond to your other points for now until we
get into the correct context.

Thanks - Fred
[e-mail]

> 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