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

[David Farmer <[e-mail]>]

On Wed, Nov 18, 2020 at 4:20 PM Brian E Carpenter <
[e-mail]> wrote:

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

Isn't that effectively the GROW WG.
https://datatracker.ietf.org/wg/grow/about/


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

If any of the routes are announced to the DFZ, per airline or other major
ATC infrastructure operator like an airport, etc... makes sense and yes per
airplane doesn't in most cases. But, I'm not sure how many will announce
ATC infrastructure to the DFZ anyway. I believe they are looking for global
uniqueness, not necessarily global reachability


> How about an ops Area draft describing how the proposal works with BGP4
> and how many new BGP routes it will create?
>

The issue of how many routes would be in the DFZ needs discussion, but so
do several other issues. I think many of the things discussed in this
thread should be put in an Internet-Draft, along with a good reference to
the ICAO working document and a summary of the working document because I
don't think it is freely available.


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


-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================