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

["Manfredi (US), Albert E" <[e-mail]>]

Fred,

Well, it does seem like a fix layered on top of something that was inherently wrong, no?

IPv6 address architecture is not the same as NSAPA. Tools are designed to do a certain job, and in this case, the tool was being misused, is what I've come to understand.

Bert

-----Original Message-----
From: ipv6 <[e-mail]> On Behalf Of Templin (US), Fred L
Sent: Wednesday, November 18, 2020 16:28
To: Brian E Carpenter <[e-mail]>; Tony Whyman <[e-mail]>; [e-mail]
Subject: Re: Extending a /64 (The most welcome comment)

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