Re: [EXTERNAL] Re: Extending a /64 (The most welcome comment)

[Tony Whyman <[e-mail]>]

Pascal,

I was assuming Basic NEMO in my example. But please note that this was 
an example and is no more than a baseline. In practice, we are looking 
for something better and are evaluating both LISP and AERO based approaches.

Regards

Tony

On 19/11/2020 10:14, Pascal Thubert (pthubert) wrote:
> Hello Tony
>
> Just to clarify I expect that by Mobile IP you specifically mean NEMO (RFC 3963), which is for a mobile router that carries an MNP, correct?
>
> Keep safe;
>
> Pascal
>
>> -----Original Message-----
>> From: ipv6 <[e-mail]> On Behalf Of Tony Whyman
>> Sent: jeudi 19 novembre 2020 09:42
>> To: Templin (US), Fred L <[e-mail]>; Brian E Carpenter
>> <[e-mail]>; [e-mail]
>> Subject: Re: [EXTERNAL] Re: Extending a /64 (The most welcome comment)
>>
>> On 18/11/2020 22:27, Templin (US), Fred L wrote:
>>> Brian,
>>>
>>>> How about an ops Area draft describing how the proposal works with BGP4
>> and how many new BGP routes it will create?
>>> I am not well liked in ops, but if Tony is up for another document and
>>> has enjoyed the IETF "ride" thus far sure why not. What do you think, Tony?
>>>
>>> Fred
>> Fred,
>>
>> Not sure if I really understand the question. As we both know, BGP routes to
>> mobiles are not readily aggregatable. They are also subject to an unusually high
>> rate of change resulting in potential forwarding table volatility. If you go down
>> the BGP path then some sort of containment strategy is required, as you have
>> specified for AERO and which itself draws on the way the ATN/OSI works with
>> IDRP routes. Outside the containment area only a highly aggregated route to all
>> mobiles is ever advertised.
>>
>> Alternatively, Mobile IP avoids the problem by aggregating mobile routes
>> effectively within the Home Agent and advertising only an aggregated route to
>> some collective Home Network. A LISP based approach does not even work
>> with BGP in the EID-space, although an xTR Proxy might advertise a highly
>> aggregated route to all mobiles to the wider internet.
>>
>> As for the "ride" - next time I'll confine myself to the simpler problem of
>> delivering World Peace.
>>
>> Tony
>>
>>
>>>> -----Original Message-----
>>>> From: Brian E Carpenter [mailto:[e-mail]]
>>>> Sent: Wednesday, November 18, 2020 2:20 PM
>>>> To: Templin (US), Fred L <[e-mail]>; Tony Whyman
>>>> <[e-mail]>; [e-mail]
>>>> Subject: [EXTERNAL] Re: Extending a /64 (The most welcome comment)
>>>>
>>>> Fred,
>>>>
>>>> My concern isn't about what happens inside the ICAO limited domain.
>>>> What you say makes complete sense there. It's about how these
>>>> prefixes (fail to) aggregate in what we used to call the default-free zone.
>> (RFC1888 probably would have had that problem too, but as far as I know,
>> nobody ever implemented it.) If there was a bgpops WG, that would be the
>> place to discuss it.
>>>> If the plan creates a new DFZ route for each airline, that's a
>>>> negligible number in the BGP4 context. If it creates a new DFZ route for each
>> aircraft, that could be problematic.
>>>> How about an ops Area draft describing how the proposal works with BGP4
>> and how many new BGP routes it will create?
>>>> Regards
>>>>      Brian
>>>>
>>>> On 19-Nov-20 10:27, Templin (US), Fred L wrote:
>>>>> Brian, there will be many non-airplane users of the ATN/IPS
>>>>> top-level IPv6 prefix allocation - often in fixed and non-mobile
>>>>> environments - and we can expect them to conform to CIDR
>>>>> conventions. We are only talking here about the airplanes, which are
>> always mobile and always away from "home".
>>>>> I have shown how we can route their prefixes using scalable
>>>>> de-aggregation, and you seemed to concur. So, why can't we tolerate
>>>>> a 24-bit portion of the airplane's prefix that does not come from a strict
>> CIDR hierarchy?
>>>>> Fred
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E
>>>>>> Carpenter
>>>>>> Sent: Wednesday, November 18, 2020 12:10 PM
>>>>>> To: Tony Whyman <[e-mail]>;
>> [e-mail]
>>>>>> Subject: [EXTERNAL] Re: Extending a /64 (The most welcome comment)
>>>>>>
>>>>>> Tony,
>>>>>>
>>>>>> I don't like the argument that people are arguing for either "purity"
>>>>>> or "perfection". That is not the issue. The issue is doing
>>>>>> something that matches how IPv6 wide-area routing actually works,
>>>>>> and that is by CIDRised prefix allocation.
>>>>>>
>>>>>> Now you have peeled back the onion to this point:
>>>>>>
>>>>>>> we have to have an addressing plan (for
>>>>>>> aircraft) that is canonical with the existing NSAP Address.
>>>>>> I understand that as a perceived requirement; it's more or less why
>>>>>> we wrote RFC1888, although mapping US GOSIP addresses was the
>>>>>> target then. I don't know how the ICAO lays out its NSAPA
>>>>>> addresses, but I imagine that the aircraft ID is towards the low-order bits?
>>>>>> That's where it should be in an IPv6 address, IMNSHO.
>>>>>>
>>>>>> The current proposal seems to be limited to 16 subnets on an
>>>>>> aircraft and that is highly likely to come back and bite you.
>>>>>>
>>>>>> Regards
>>>>>>      Brian Carpenter
>>>>>>
>>>>>> On 18-Nov-20 22:33, Tony Whyman wrote:
>>>>>>> On 18/11/2020 03:30, Michael Richardson wrote:
>>>>>>>> When we designed IPv6, we assumed that everyone would get some,
>>>>>>>> even if they didn't connect.
>>>>>>>>
>>>>>>>>        > ULAs only have the first property.
>>>>>>>>        > If a device doesn't need the second property, the device doesn't
>> need a GUA.
>>>>>>>> Again, what is this business of trying to ration IPv6?
>>>>>>>> Do they really need 39 bits? I don't know.
>>>>>>>>
>>>>>>>> Our entire Ipv6 architecture ENCOURAGES entities to ask for the
>>>>>>>> amount of space that they think they might need over the lifetime
>>>>>>>> of their effort and NEVER COME BACK for more.
>>>>>>>>
>>>>>>>> That's why /64 for IIDs, and /48s for every site.
>>>>>>> If there is another edition of RFC 8200 then the sentence
>>>>>>> beginning "Our entire.." should be copied to the front page of the
>>>>>>> new edition. Yes, we all get the idea that addressing plans should
>>>>>>> be as elegant as possible
>>>>>>> - but IPv4-think should have no place in this. But, perhaps the
>>>>>>> most important notion that comes through in the above is that each
>>>>>>> industry ultimately knows best when it comes to the compromises
>>>>>>> that have to be made to create an industry specific addressing plan.
>>>>>>>
>>>>>>> Over the last few days, I have been happy to try and peel away the
>>>>>>> issues that lay behind our proposed IPv6 addressing plan and to
>>>>>>> use it as an opportunity to spread understanding of the ATN/IPS
>>>>>>> and the constraints under which we are working. However, there is
>>>>>>> one point that it seems to be too difficult for some to get their
>>>>>>> head around and that is that we are not starting with a "clean
>>>>>>> sheet of paper". We have to respect the constraints that we have
>>>>>>> and sometimes arguably poor decisions that were made in the past
>>>>>>> and the result is a compromise. It will offend those who demand purity -
>> but purity is not the objective.
>>>>>>> The objective is to deploy a working IPv6 based system.
>>>>>>>
>>>>>>> In the ICAO Working Groups, we are writing the 3rd edition of the
>>>>>>> ATN/IPS Manual. There were two earlier versions and both represent
>>>>>>> failed attempts to deliver an IPS based ATN. They failed - not
>>>>>>> necessarily for technical reasons - but because there was no
>>>>>>> business case. This is a very hard nosed industry and, unless its
>>>>>>> use is commanded by regulation, if a new technology does not
>>>>>>> deliver more passengers or raise the profit/passenger then it ain't going
>> to happen.
>>>>>>> Even now, I am hard pressed to see any business case for an
>>>>>>> ATN/IPS replacing the venerable ATN/OSI. The ATN/OSI is a CLNP
>>>>>>> overlay on top of an IPv4 network, it works, with some
>>>>>>> limitations, and will support the current generation of
>>>>>>> applications. With nugatory upgrades it could support the next
>>>>>>> generation. Some might point to presumed cost savings by replacing
>>>>>>> CLNP with something that is industry mainstream - but the truth is
>>>>>>> that the CLNP bits are, by and large, in systems that perform
>>>>>>> functions that are unique to civil aviation, while the rest is catalogue
>> item routers.
>>>>>>> However, looking to the long term, it will be increasingly
>>>>>>> difficult to develop new applications on the ATN/OSI base and we
>>>>>>> should seize the first opportunity that we can find to move on to an
>> ATN/IPS.
>>>>>>> A funding window has opened up with the European Space Agency
>>>>>>> (ESA) and the EU's SESAR research programme putting in the funds
>>>>>>> to develop a prototype SATCOM service for the ATN/IPS. This should
>>>>>>> just about extend to cover initial avionics on a single aircraft
>>>>>>> type (different generations of aircraft have different
>>>>>>> communication architectures and everything has to be type approved
>>>>>>> before it can be used). The funding should also cover a protocol
>>>>>>> gateway allowing the prototype to interwork with ATC Centres i.e.
>>>>>>> to at least demonstrate an operational service using the ATN/IPS.
>>>>>>>
>>>>>>> Even stretching the funding envelope this far is optimistic.
>>>>>>> Adding in anything else like a new registration scheme for
>>>>>>> aircraft and lookup tables in the protocol gateway will kill the
>>>>>>> project financially. Yes, I know that these are not technically
>>>>>>> difficult, but when you work in an environment where every new
>>>>>>> function has to be subject to a hazard analysis, a safety case, a
>>>>>>> high end develop lifecycle and rigorous testing then, what looks
>>>>>>> like a simple function on paper, quickly gets replaced by a dollar sign
>> followed by lots of digits.
>>>>>>> To keep this project feasible, we have to have an addressing plan
>>>>>>> (for
>>>>>>> aircraft) that is canonical with the existing NSAP Address. You
>>>>>>> may prefer purity and demand that we have a perfect addressing
>>>>>>> plan. But you are not helping.
>>>>>>>
>>>>>>> Our goal is to get a working ATN/IPS on to a single aircraft type
>>>>>>> with minimum change to the existing system. Once this has been
>>>>>>> demonstrated to be feasible and "industry mainstream" then the
>>>>>>> case can be made for rolling it out to other aircraft types and,
>>>>>>> may be, one day, even the ATC Centre's will get upgraded - but
>>>>>>> that will probably have wait until a new application provides the
>> business case.
>>>>>>> Perhaps another aphorism that could be put on the front page of a
>>>>>>> future version of RFC 8200 is "never let the perfect be the enemy of the
>> good".
>>>>>>> Regards
>>>>>>>
>>>>>>> Tony Whyman, MWA
>>>>>>>
>>>>>>> PS: we could always declare the ATN as a closed network and use
>>>>>>> our own addressing plan - but does not help make the "industry
>>>>>>> mainstream" case, does it.
>>>>>>>
>>>>>>> ------------------------------------------------------------------
>>>>>>> -- IETF IPv6 working group mailing list [e-mail]
>>>>>>> Administrative Requests:
>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>> ------------------------------------------------------------------
>>>>>>> --
>>>>>>>
>>>>>> -------------------------------------------------------------------
>>>>>> - IETF IPv6 working group mailing list [e-mail] Administrative
>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> -------------------------------------------------------------------
>>>>>> -
>>>>> .
>>>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------