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

[Brian E Carpenter <[e-mail]>]

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