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

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 18 Nov 2020 21:27:50 +0000

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:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Wednesday, November 18, 2020 12:10 PM
> To: Tony Whyman <[email-masked]>; [email-masked]
> 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
> > [email-masked]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 18 Nov 2020 21:33:38 +0000

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 <[email-masked]> On Behalf Of Templin (US), Fred L
Sent: Wednesday, November 18, 2020 16:28
To: Brian E Carpenter <[email-masked]>; Tony Whyman <[email-masked]>; [email-masked]
Subject: Re: Extending a /64 (The most welcome comment)

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Nov 2020 11:20:24 +1300

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 18 Nov 2020 22:27:18 +0000

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

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, November 18, 2020 2:20 PM
> To: Templin (US), Fred L <[email-masked]>; Tony Whyman <[email-masked]>; [email-masked]
> 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.
>

---

From: David Farmer <[email-masked]>
Date: Wed, 18 Nov 2020 16:54:08 -0600

On Wed, Nov 18, 2020 at 4:20 PM Brian E Carpenter <
[email-masked]> 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.

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

---

From: Tony Whyman <[email-masked]>
Date: Thu, 19 Nov 2020 08:41:47 +0000

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 Nov 2020 10:14:08 +0000

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 

> From: ipv6 <[email-masked]> On Behalf Of Tony Whyman
> Sent: jeudi 19 novembre 2020 09:42
> To: Templin (US), Fred L <[email-masked]>; Brian E Carpenter
> <[email-masked]>; [email-masked]
> Subject: Re: [EXTERNAL] Re: Extending a /64 (The most welcome comment)
> 
> > 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.
> 
> 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
> 
> 
> >
> >> To: Templin (US), Fred L <[email-masked]>; Tony Whyman
> >> <[email-masked]>; [email-masked]
> >> 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
> >>> 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
> >>>
> >>>> 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.
> >>>>
> >>>> 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?
> >>>>>> When we designed IPv6, we assumed that everyone would get some,
> >>>>>> even if they didn't connect.
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>> 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.
> >>>>>
> >>>>> 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.
> >>>>> 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
> >>>>> 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.
> >>>>>
> >>>>> 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 [email-masked]
> >>>>> Administrative Requests:
> >>>>> https://www.ietf.org/mailman/listinfo/ipv6
> >>>> -------------------------------------------------------------------
> >>>> - IETF IPv6 working group mailing list [email-masked] Administrative
> >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Tony Whyman <[email-masked]>
Date: Thu, 19 Nov 2020 11:05:32 +0000

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