Subject: [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 18:42:42 -0300

Folks,

If you haven't been following recent developments in the Spring WG, you 
may be surprised about some of the work that is being pursued (or was 
being pursued)-

Such work has included proposing that some IPv6 routers insert and 
remove routing headers en-route to the final destination.

After many very heated and lengthy debates, some of this work was 
dropped, but other remains (e.g. routers removing IPv6 EHs from packets 
en-route to their final destination, part of what they call "PSP"). For 
the most part, the proponents have argued that "we have implemented it, 
and the industry wants it" -- as if we just have to rubberstamp what 
they have done.

On the technical side, the proponents have argued that:

     If a packet employs source routing (and hence its Destination
     Address is modified en-route to direct the packet through each
     of these "waypoints"), then any of such "waypoint" routers are
     free to add or remove IPv6 extension headers at will. (No, not
     encap/decap, but rather add/remove EHs from the IPv6 header
     chain).

That seems to me like a very major deviation from what's supposed to be 
our current "architecture", where IPv6 is an end to end protocol. 
Besides, it should be obvious that removal/insertion of EHs en-route 
error reporting (since host typically check that the ICMP errors they 
receive correspond to something that they actually sent).

A number of us have raised this a number of times, and at least some of 
us feel that our concerns are being ignored.

It would seem to me that these documents and decisions have a concrete 
impact on our architecture, and that they are being pursued without any 
proper oversight. There is also a widespread feeling that having one or 
a few big vendors pushing these ideas might be playing a role here.

(See, for instance:

* https://mailarchive.ietf.org/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXvPcpj4/

* https://mailarchive.ietf.org/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc/
)

What I would expect is that all thes major changes to our existing 
architecture and protocols would only done by formally updating existing 
standards *if* deemed appropriate, as opposed to just trying to sneak 
changes "when nobody is watching", or by having very curious 
interpretations of our protocols and standards.

I've raised the topic to our AD (Suresh), to the IAB, and on the arch-d 
list before, but so far haven't been lucky or seen anything meaningful 
happen in this area.

I have also submitted an errata to make RFC8200 even more clear on the 
topic, but it remains unprocessed.

So my questions are:

* On the technical area:

  + Is IPv6 an End To End protocol?  Or is the IETF's stance that 
routers are free to mangle with the packet structure as they please?

  + Was IPv6 designed that way? And if it wasn't, when/how was the 
architecture changed?

* On the procedural area:

   + Where/how should IETF WGs seek for architecture-related advice?

   + What do do in situations like the above?  Wait and see how things
     evolve, and upon any formal decisions, just submit formal Appeals
     if deemed necessary?  (and after way too much energy consumed from
     everyone)

     I would have expected that as soon as these issues were raised,
     the offending text would be removed rightaway. But that wasn't
     the case. And when the changes did happen, it wasn't without
     an extraordinary waste of time and energy from all of us.
     For instance, any work on IPv6 header insertion/deletion wouldn't
     seem to fit within the charters of the 6man or spring wgs.

     FWIW, this is not the first instance of issues surrounding the same
     topic. It goes back to the rfc2460bis effort, when a similar set of
     folks (too many from one big vendor) got to have 6man ship
     what became RFC8200 with a noted "ambiguity", just to be able
     to have some playground for EH insertion/deletion. And we only got
     to improve on that during IETF LC:

    (see: 
https://mailarchive.ietf.org/arch/msg/ipv6/Kp76SONpyqWneNgvtc8sh-fGAu0/)

Thoughts or advice on the technical and/or procedural aspects will be 
appreciated.

Thanks!

Cheers,
Fernando

-------- Forwarded Message --------
Subject: Errata #5933 for RFC8200
Date: Thu, 27 Feb 2020 17:07:36 -0300
From: Fernando Gont <[email-masked]>
To: Suresh Krishnan <[email-masked]>
CC: [email-masked] <[email-masked]>

Suresh,

Two months ago I filled an errata on RFC8200 regarding the processing of 
IPv6 extension headers. The errata is available here: 
https://www.rfc-editor.org/errata/eid5933

While I believe that folks with a knowledge of Internet Protocols would 
be able to interpret what is in RFC8200, given recent discussions on the 
topic, and upon a re-read of the text, I believe a clarification is 
warranted, such that we allow all sorts of curious interpretations of 
the text.

I send a heads-up on the 6man mailing list 
(https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/), 
and the proposed text received the review of at least Brian Carpenter, 
Ron Bonica, and Mark Smith. Their reviews are available on such thread.

In the light that some folks seem to be pretending to leverage "the lack 
of clarify" in RFC8200 (an Internet Standard) to violate it, I'd 
appreciate that the reported errata be processed.

Processing the aforementioned errata is key to many of the discussions 
this and other WGs are having.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tom Herbert <[email-masked]>
Date: Thu, 27 Feb 2020 14:07:33 -0800

Fernando,

I think we need to be careful that IETF is labeled as a collection of
inflexible architectural purists. We know that standards conformance
is voluntary and we haven't seen the last time that someone, possibly
even a major vendor, will circumvent the system for their own
purposes. IMO extension header insertion is a great example of that.
On one hand we have people quoting IPv6 saying that it isn't allowed
per RFC8200-- period! And on other side there are proponents that see
a real need for it and believe they have clear use case-- at one
presentation in IETF a proponent bluntly stated that regardless of any
discussion in IETF they're going to do it! IMO, what we haven't seen,
was a real attempt to resolve and work out the engineering issues.
That's not for lack of trying-- for instance I proposed a direction to
try for an engineering compromise in draft-herbert-6man-eh-attrib-00,
but saw little discussion on that.

Tom

On Thu, Feb 27, 2020 at 1:43 PM Fernando Gont <[email-masked]> wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 19:15:42 -0300

Tom,

If you read my email carefully, I said:

    What I would expect is that all these major changes to our existing
    architecture and protocols would only done by formally updating
    existing standards *if* deemed appropriate, as opposed to just trying
    to sneak changes "when nobody is watching", or by having very curious
    interpretations of our protocols and standards.

That's not an argument against formally changing a spec.

But it *is* an argument against:

   * Violating specs at ill

   * Changing specs while pretending you don't

   * Applying major changes to the architecture without proper oversight.

Thanks,
Fernando

On 27/2/20 19:07, Tom Herbert wrote:
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Feb 2020 17:26:28 -0500

On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert <[email-masked]> wrote:

> purposes.

IP end to end does not mean the IP address is constant end to end. It never
has meant that and never will. An IP address is merely a piece of data that
allows a packet to reach its destination. There is no reason to insist on
it remaining constant along the path.

The sooner people get over that fact the better.

If an IPv4 device interacts with an IPv6 device, there will be address
translation going on somewhere along the path. That is inevitable.

We discovered that there were good reasons for NATing IPv4 besides address
multiplexing. The topology of my network is none of your business.

More generally, Internet standards only apply to the Inter-net, the network
of networks. What happens inside the networks at either end is for the
owners of those networks to decide. If we go back to the original Internet
design, they didn't even need to run IP. IP end to end come later.

So let us stop being dogmatic about things that don't actually matter. The
only job of the network layer is to get packets from one end to another.
The only job of the transport layer is to provide reliable streams. An
application protocol that depends on the IP address remaining constant end
to end is a bad protocol and should be rejected.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Feb 2020 23:38:50 +0100

This below note deserves to be printed and framed ! Spot on.

On Thu, Feb 27, 2020 at 11:26 PM Phillip Hallam-Baker <[email-masked]>
wrote:

> IP end to end does not mean the IP address is constant end to end. It
> never has meant that and never will. An IP address is merely a piece of
> data that allows a packet to reach its destination. There is no reason to
> insist on it remaining constant along the path.
>
> More generally, Internet standards only apply to the Inter-net, the
> network of networks. What happens inside the networks at either end is for
> the owners of those networks to decide. If we go back to the original
> Internet design, they didn't even need to run IP. IP end to end come later.
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 27 Feb 2020 14:43:10 -0800

Fernando --

"the proponents have argued that "we have implemented it,
and the industry wants it" -- as if we just have to rubberstamp what
they have done."

[BA] The IETF has no enforcement authority, so that vendors have the
ability to ship products implementing IETF standards in whole or in part -
or not at all.  However, it is within the authority of the IETF to define
requirements, and to articulate the implications of behavior that (some
people) might consider undesirable, so as to provide information so that
customers can make their own decisions.

"Besides, it should be obvious that removal/insertion of EHs en-route
error reporting (since host typically check that the ICMP errors they
receive correspond to something that they actually sent)."

[BA] This is an example of a consequence that should be considered. IMHO,
these issues are worth writing up.

Tom said:

"IMO, what we haven't seen, was a real attempt to resolve and work out the
engineering issues."

[BA] In practice, these kind of issues are rarely "resolved" - points of
contention in "Tussle space" go through cycles of
deployment/analysis/reaction.  So sometimes rather than seeking
"compromise" (which may satisfy noone) it is better to put publish both a
majority and a minority opinion.  This approach not only clarifies the
points of debate, but also puts the positions on record for posterity.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 27 Feb 2020 14:44:35 -0800

> to end is a bad protocol and should be rejected.

So Authentication Header and any other sort of Inetwork layer
authentication are bad protocols that should be rejected?

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Feb 2020 14:47:47 -0800

On 2020-02-27 14:26, Phillip Hallam-Baker wrote:

> IP end to end does not mean the IP address is constant end to end. It never has meant that and never will.

Actually, that's the only thing it ever meant and always will. When
addresses change, *by definition*, the*ends* change (and yes, that's
what NATs do - they create end-to-end CONTENT transfer over separate
end-to-end Internets). 

> ..
> We discovered that there were good reasons for NATing IPv4 besides address multiplexing. The topology of my network is none of your business.

Agreed; there's nothing that forces you to use IP addresses in a way
that exposes your topology (you're free to build a net using host
routing). That has nothing to do with NAT. 

I have not found a rationale for NATs that doesn't start and end with a
business model where servers are charged business rates and clients are
charged customer rates. Everything else about NATs either isn't a NAT
property (hiding topology) or can be achieved by a stateful firewall
(that predates NATs by a decade, e.g. that lets outgoing connections go
through but not incoming). 

> More generally, Internet standards only apply to the Inter-net, the network of networks. What happens inside the networks at either end is for the owners of those networks to decide. If we go back to the original Internet design, they didn't even need to run IP. IP end to end come later.

That's true, but then their "end" on the public Internet would be the
firewall or NAT box at their edge. 

> So let us stop being dogmatic about things that don't actually matter. The only job of the network layer is to get packets from one end to another. The only job of the transport layer is to provide reliable streams. An application protocol that depends on the IP address remaining constant end to end is a bad protocol and should be rejected.

That's a very OSI view of protocols - about as out-dated and about as
useful., IMO. Every layer of the stack might be involved in any
function; anything that claims a single layer owns a single job hasn't
existed since at least IP over IP. 

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 19:50:16 -0300

Philip,

On 27/2/20 19:26, Phillip Hallam-Baker wrote:
> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Fernando,
> 
> data that allows a packet to reach its destination. There is no reason 
> to insist on it remaining constant along the path.

You seem to be missing the point I was trying to make.

We're talking about IPv6 routers doing heavy surgery on IPv6 packets, 
while en-route to destination.

And we are also talking about violating IETF specs at will, and 
circumventing IETF processes.

This does break things, make troubleshooting painful, etc.

AH may break
PMTUD may break
Error may reporting break

I'm not being purist. I'm just arguing that we probably can do better 
than simply rubber-stamping any hacks a vendor with big pockets may 
bring up.

Otherwise, I don't see the point of all this big structure.

For instance, we have an "Internet Architecture Board", which I guess 
have a say on things that affect architecture?

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Feb 2020 14:52:27 -0800

FWIW - there are separable issues here: 

- whether an IP header (or parts thereof) should be changed in transit 

AFAICT, the answer has always been yes, but limited to the hopcount/ttl
in the base header and hop-by-hop options in the options/extension
headers. 

- whether an IP header length can change in transit 

I see no reason why it can't become smaller, but if it can become larger
then PMTUD and PLPMTUD don't work. 

So the question isn't just what is wanted, it's what is feasible. 

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Feb 2020 14:58:17 -0800

On 2020-02-27 14:50, Fernando Gont wrote:

> ...
> I'm not being purist. I'm just arguing that we probably can do better than simply rubber-stamping any hacks a vendor with big pockets may bring up.

That's a refreshing perspective. 

Refreshing, but confusing - given you promoted "standardizing" vendor
deviations (many arguably bugs) from TCP in TCPM. 

So I'm confused - what do you think drives our standards now? Design or
implementations (including bugs)? 

Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 27 Feb 2020 15:00:52 -0800

On Thu, Feb 27, 2020 at 2:52 PM Joe Touch <[email-masked]> wrote:
> AFAICT, the answer has always been yes, but limited to the hopcount/ttl in the base header and hop-by-hop options in the options/extension headers.
>
> I see no reason why it can't become smaller, but if it can become larger then PMTUD and PLPMTUD don't work.
>
Joe,

Per the problem about making packets larger in the network, I'd point
out that this is already common due to in-network tunneling. In any
case, it's really the only interesting case here (as opposed to making
packets smaller).

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Feb 2020 15:05:04 -0800

> case, it's really the only interesting case here (as opposed to making

Tunnels don't make packets bigger. They make a bigger packet at the
tunnel level. That then becomes the tunnel's problem to deal with (see
draft-intarea-tunnels). 

Making the IP packet bigger itself creates a problem that cannot be
recovered that way. 

I.e., same problem but very different consequences. 

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 20:06:44 -0300

On 27/2/20 19:52, Joe Touch wrote:
> in the base header and hop-by-hop options in the options/extension headers.
> 

Besides AH (which obviously breaks), hosts typically try to validate 
that the error messages they receive correspond to something they 
actually sent.

EH removal breaks that.

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Feb 2020 15:07:51 -0800

Hi, Robert, 

It doesn't matter on what IP header this occurs. 

It does matter whether it happens at the IP source (origin host, tunnel
ingress, etc.) or on the path of that header. 

The former is allowed exactly because it is where source fragmentation
can occur (in IPv6, and preferably the only kind of fragmentation used
in IPv4). 

Joe

On 2020-02-27 15:04, Robert Raszuk wrote:

> Joe, all, 
> 
> Just to clarify something Fernando purposely missed in his call for action: 
> 
> All operations on the packets discussed in SPRING WG are happening NOT on the original (end to end) packet header. They are all defined to happen within new imposed outer encapsulated header (IPv6 in IPv6 to be precise).  
> 
> So original packet just get's tunneled between various points of the network. Last time I checked that operation is allowed by RFC2473.  
> 
> Its subtle detail, but fundamental one to this entire context/discussion. 
> 
> Kind regards, 
> R. 
> 
> On Thu, Feb 27, 2020 at 11:54 PM Joe Touch <[email-masked]> wrote: 
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 19:58:25 -0300

On 27/2/20 19:43, Bernard Aboba wrote:
> ability to ship products implementing IETF standards in whole or in part 
> - or not at all.  

Agreed. The problem here is that it's an *IETF* working group 
rubber-stamping what a vendor did. *That* is the problem.

May I ask what is the point of bothering publishing specs if they are 
going to be violated at will *within the same organization that 
published the specs*.

As noted by Jinmei here 
<https://mailarchive.ietf.org/arch/msg/spring/XZ_D_cfPNNzXpi4_ZbuTidMTo4k/> 
, I believe not only are we just rubber-stamping stuff, but also I 
believe that our processes are being circumvented.

Thanks,

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 00:10:59 +0100

It happens on tunnel ingress and tunnel egress nodes (egress = node listed
in DA of the packet).

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Feb 2020 15:13:39 -0800

On 2020-02-27 15:10, Robert Raszuk wrote:

>> It does matter whether it happens at the IP source (origin host, tunnel ingress, etc.) or on the path of that header. 
> It happens on tunnel ingress and tunnel egress nodes (egress = node listed in DA of the packet).

Ingress can create whatever header it wants but needs to do
fragmentation (and potentially PLPMTUD over the tunnel with the egress).

Egress can strip the outer header but not make the inner one bigger,
IMO. 

Is something else being proposed? 

Joe

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 00:04:43 +0100

Joe, all,

All operations on the packets discussed in SPRING WG are happening NOT on
the original (end to end) packet header. They are all defined to happen
within new imposed outer encapsulated header (IPv6 in IPv6 to be precise).

So original packet just get's tunneled between various points of the
network. Last time I checked that operation is allowed by RFC2473.

Kind regards,
R.

On Thu, Feb 27, 2020 at 11:54 PM Joe Touch <[email-masked]> wrote:

> AFAICT, the answer has always been yes, but limited to the hopcount/ttl in
> the base header and hop-by-hop options in the options/extension headers.
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 00:15:19 +0100

>  Is something else being proposed?

No. What you said below is exactly what is proposed.

Thank you,
r.

On Fri, Feb 28, 2020 at 12:13 AM Joe Touch <[email-masked]> wrote:

> Ingress can create whatever header it wants but needs to do fragmentation
> (and potentially PLPMTUD over the tunnel with the egress).
>
> Egress can strip the outer header but not make the inner one bigger, IMO.
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Feb 2020 15:21:07 -0800

EH isn't a HBH option or extension. 

Joe 

On 2020-02-27 15:06, Fernando Gont wrote:

> Besides AH (which obviously breaks), hosts typically try to validate that the error messages they receive correspond to something they actually sent.
> 
> EH removal breaks that.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 20:36:41 -0300

Joe,

What draft-ietf-spring-srv6-network-programming proposes is to remove a 
segment routing header (SRH) along the packet delivery path, before the 
packet arrives at the final destination. They call it PSP.

Before, folks have also proposed to insert Extension Headers (EHs) while 
packets are en-route to their intended destination, etc.

Thanks,
Fernando

On 27/2/20 20:21, Joe Touch wrote:
>>> AFAICT, the answer has always been yes, but limited to the 
>>> hopcount/ttl in the base header and hop-by-hop options in the 
>>> options/extension headers.
>>>
>>> I see no reason why it can't become smaller, but if it can become 
>>> larger then PMTUD and PLPMTUD don't work.
>>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Feb 2020 10:54:37 +1100

> On 28 Feb 2020, at 10:00, Tom Herbert <[email-masked]> wrote:
> 

Encapsulation doesn’t make the packet larger.  It is no different to
talking a packet from a ethernet and pushing it out a PPP link.  The
Enclosing headers differ in sizes but the IPv6 packet remains the
same size.

The difference with encapsulation, from the non encapsulation cases, is
that PTBs are sent to the encapsulating node which has to synthesis a
PTB to the original (as far as the encapsulating node is concerned)
sender when they are received with the MTU reduced by the encapsulation
overhead and the encapsulation header removed from the PTB payload.  The
sender of the un-encapsulated packet sees PTB with a MTU which will allow
future packets pass both the encapsulating node and the node which generated
the PTB of the encapsulated packet and the packet headers it originally sent.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 00:58:11 +0100

> packet arrives at the final destination. They call it PSP.

That removal as it has been explained to you many times happens at the node
which is explicitly listed as DA of the packet.

> packets are en-route to their intended destination, etc.

That has been moved to a separate draft to move fwd with the rest of the
work.

Yes this is still useful for TI-LFA (as example).

We need to ask ourselves what is more important ... quality of data plane
for end users with 10s of ms of connectivity restoration times upon failure
or keeping original IPv6 dogmas in place where folks never envisioned such
needs or technologies to be invented.

Rgs,
R.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Feb 2020 19:21:43 -0500

On Thu, Feb 27, 2020 at 5:47 PM Joe Touch <[email-masked]> wrote:

> never has meant that and never will.
>
>
> addresses change, *by definition*, the*ends* change (and yes, that's what
> NATs do - they create end-to-end CONTENT transfer over separate end-to-end
> Internets).
>

By whose definition? Not by mine.

TCP and TLS give me a reliable end-to-end stream. The fact that the IP
address is exposed is merely an unfortunate defect in the legacy APIs.

As the application layer designer, I am the customer here. I do not care
about the IP address.

> Agreed; there's nothing that forces you to use IP addresses in a way that
> exposes your topology (you're free to build a net using host routing). That
> has nothing to do with NAT.
>
> property (hiding topology) or can be achieved by a stateful firewall (that
> predates NATs by a decade, e.g. that lets outgoing connections go through
> but not incoming).
>

Then you have had a remarkably sheltered upbringing.

Concealing details of the internal network structure is only common sense.

> firewall or NAT box at their edge.

There isn't a single 'end' in a protocol which is one of the reasons
end-to-end security has been done so badly. If Alice sends Bob a business
email, we have the following ends:

1) Application layer: SUBMIT Client -> SUBMIT Service, SMTP Client -> SMTP
Service, IMAP Client -> IMAP Service.
2) Message layer: Alice Email client -> Bob Email Client
3) Trust: Alice's employer <-> Bob's employer

Feel free to introduce extra ends if you like, it is irrelevant to my
concerns at the application layer.

> useful., IMO. Every layer of the stack might be involved in any function;
> anything that claims a single layer owns a single job hasn't existed since
> at least IP over IP.
>

The notion of encapsulation has been established in the object oriented
programming world for decades. The notion that the application program
should be abstracted from the transport and network layer is hardly a
controversial one.

As for OSI, I would not know as I have not made a detailed study of it. It
is not a model I find interesting as it doesn't describe the role of the
naming systems and it isn't able to describe systems like SDN and VPN which
we make use of.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Feb 2020 19:27:41 -0500

On Thu, Feb 27, 2020 at 5:44 PM Tom Herbert <[email-masked]> wrote:

>> We discovered that there were good reasons for NATing IPv4 besides
>> address multiplexing. The topology of my network is none of your business.
>>
>> So let us stop being dogmatic about things that don't actually matter.
>> The only job of the network layer is to get packets from one end to
>> another. The only job of the transport layer is to provide reliable
>> streams. An application protocol that depends on the IP address remaining
>> constant end to end is a bad protocol and should be rejected.
>>
>

The IPSEC authentication header is a complete failure of design. It is the
reason IPSEC doesn't work in the real world and has been replaced by SSH.

Stuff that doesn't work in the real world is just bad and should be
rejected. I remember the security ADs of the time smirking as they said
IPSEC not working with NAT represented a feature, not a bug. They were
wrong then and you are wrong now.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 27 Feb 2020 16:39:17 -0800

> wrong then and you are wrong now.
Thanks for your opinion, but I see nothing of relevance here that is worth
a reply.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 27 Feb 2020 16:43:38 -0800

Fernando,

Your original question was "is IPv6 end to end".

For me, the practical test of end to end is, can it be encrypted? A
message is end-to-end if it can be sent from end point A to endpoint B
using encryption services so that it cannot be modified in transit, only
the intended destination can receive it, and that destination can verify
that it came from the specified origin. Under that definition, Quic or
TLS are end to end. UDP, TCP, IPv4 and IPv6 on which they are built, not
so much.

This may be a cynical point of view, but it matches what Bernard Aboba
mentions in his description of "tussle space". Experience shows that if
intermediaries gain benefits in messing around with data in transit,
they will. The IETF may send them RFC copies in triplicate, but that
won't stop them. In the absence of encryption, the only reason it is a
tussle and not a free for all is the fear of breaking existing
applications. The network operators will not deploy a middle-box that
breaks important services, because disruption will make them lose
customers or otherwise incur costs. Standards are helpful there, because
they constrain the players to remain within a plausible envelope. But
the strength of standards comes from their adoption, not from the ink on
the paper. For standards that are widely adopted and followed, the
players that try to deploy breakage will experience customer feedback
and lose their end of the tussle. But standards that have limited
adoption will not have that power.

You are mentioning segment routing variants. For me, they fall very much
in this tussle category. Network equipment makers believe that this
technology will make the network better in some ways -- maybe faster, or
maybe easier to manage. It is definitely a departure from Steve
Deering's IPv6 vision of a simple network happily forwarding IPv6
datagrams. But as long as the network provider maintains an end to end
IPv6 service, there probably won't be that much customer backlash. The
tussle will play elsewhere, for example if network providers try to move
from changing the implementation of the service to changing its
definition. We have seen that in the past with attempts at QoS
deployment that looked like trying to tax specific applications. Those
were rejected because the entire ecosystem believed that "a bit is a
bit". But of course, some players are going to try again.

-- Christian Huitema

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 27 Feb 2020 17:05:09 -0800

Fernando said:

"May I ask what is the point of bothering publishing specs if they are
going to be violated at will *within the same organization that
published the specs*."

[BA] The point of publishing specifications is to make them available for
evaluation and potential implementation.  It's a contribution to the
"marketplace of ideas".  As noted in RFC 5218, the imprimatur (e.g. the
standards status or stream) has little influence on acceptance.  Some
widely deployed specifications are Standards Track, others are
Informational. In practice, factors such as the availability of reference
implementations have more influence on deployment.

This levels the playing field - a single person (or small group) can design
a new protocol and put out an open source implementation, with a very good
chance that the work will be evaluated and succeed/fail on its own merits,
regardless of what "the experts" might think of it.

So if you take issue with a particular approach, offer up your own
alternative, or articulate the reasons why it is a bad idea.

Better to light a candle than to curse the darkness.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 22:34:18 -0300

Christian,

Thanks for your response! In-line...

On 27/2/20 21:43, Christian Huitema wrote:
[....]
> customers or otherwise incur costs.

There seems to be plenty of empirical evidence that that's not the case.

Not that they mean to break things, but they do -- e.g., a box that 
rewrites TCP sequence numbers, but fails to rewrite the SACK options. 
And many many others.

[....]
> datagrams. 

Don't we have a standards process for this, as in "Publish a draft that 
formally updates RFC8200, gain consensus, and get it published as RFC"?

Or, where/when did things change to "This wg has decided to violate the 
specs from another wg"?

And, more generally: does anybody do anywork or have a say on the 
architecture of the whole system?

For instance, we have an "Internet Architecture Board". Does the IAB 
have a say one the architecture and principles that we're developing 
specs within?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 22:41:47 -0300

On 27/2/20 22:05, Bernard Aboba wrote:
> [BA] The point of publishing specifications is to make them available 
> for evaluation and potential implementation.  It's a contribution to the 
> "marketplace of ideas". 

It would seem to me there's much more than that.

If that were the case, anything and everything would be published as an RFC.

Among other things, the specs we publish are supposed to be subject to a 
decent level of review, and are also supposed to be coherent groups of 
specifications.

If you have one spec that says one thing, and then you have another, 
from the same Std Org, that says the opposite, without "obsoleting" the 
former, then you end up with something that won't have a single bit of 
coherence, virtually impossible to digest by anybody else other by than 
a limited group of people that just happens to know how everyone 
violates each others specs.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 22:50:26 -0300

On 27/2/20 20:58, Robert Raszuk wrote:
[...]
> 
> We need to ask ourselves what is more important ... quality of data 
> plane for end users with 10s of ms of connectivity restoration times 
> upon failure or keeping original IPv6 dogmas in place where folks never 
> envisioned such needs or technologies to be invented.

I don't care myself about dogmas.

But there's an established process to do these things:

* You propose to change the existing behavior, and normally explain 
what's that beneficial, and maybe you elaborate on why you are not 
pursuing any possible alternatives.

* Once you gain consensus on the changes, you apply them.

And if the impact on the architecture is rather major, you probably 
better have people give a careful though about it.

Now, what has been going on in Spring is a vendor or set of vendors 
coming with a set of documents for a group to rubber-stamp, violating 
existing specs at will, with interpretations of existing specs that are 
confused beyond belief, or intentional to circumvent our existing processes.

Folks that care to "attract new people", etc., should really keep an eye 
on these things, as to many this reads like: "When there's stuff at 
stake, only big vendors get to play, with their own rules".

I'll refer to Jinmei's email, which esentially conveys the same message 
<https://mailarchive.ietf.org/arch/msg/spring/hmmgQygE0qIhOrt4Ii_1ANDQgHM/>

Thanks,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Feb 2020 21:18:22 -0500

> * Once you gain consensus on the changes, you apply them.

That was the OSI model.

The Internet was based on a model of permisive experimentation.

The IETF is a catalyst for generating the necessary critical mass for
deployment. But some deployments don't need a catalyst.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 28 Feb 2020 00:04:41 -0300

On 27/2/20 23:18, Phillip Hallam-Baker wrote:
> 
> 
> On Thu, Feb 27, 2020 at 8:52 PM Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

Huh? What does OSI ahve to do with that???  I'm referring to existing 
IETF process to publish a spec.

And that's the procedure/rules that are normally applied to some of us, 
mere mortals that don't happen to be working for a big vendor.

> deployment. But some deployments don't need a catalyst.

Then I suggest you email the webmaster at www.ietf.org, because the text 
there must be outdated, then.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 27 Feb 2020 19:28:42 -0800

On Thu, Feb 27, 2020 at 3:58 PM Robert Raszuk <[email-masked]> wrote:
> That removal as it has been explained to you many times happens at the node which is explicitly listed as DA of the packet.
>
> That has been moved to a separate draft to move fwd with the rest of the work.
>
> We need to ask ourselves what is more important ... quality of data plane for end users with 10s of ms of connectivity restoration times upon failure or keeping original IPv6 dogmas in place where folks never envisioned such needs or technologies to be invented.
>
Robert,

To me, security, robustness, and interoperability are more important
than performance for end users. We obviously want everything, and
IETF's part in this seems to be ensuring those sort of attributes in
standard protocols.

There's a lot of history here. If you go back through the 6man
archives, you'll find there was substantial technical discussion on
extension header insertion. There were specific concerns raised
particular concerns about the loss of attribution of packet contents.
The extension header proponents did not adequately address those
concerns. I don't believe there was ever consensus in 6man that
outright rejected the idea, but neither there wasn't much effort by
the proponents to establish consensus for the proposal. It was their
impetus to do that (frankly, publicly saying "regardless of any
discussion in IETF, the protocol is going to go forward" hurt the
cause). To say that the proponents have only been met only with dogma
would be a mischaracterization of what actually transpired.

Tom

> Rgs,
> R.
>
>
> On Fri, Feb 28, 2020 at 12:37 AM Fernando Gont <[email-masked]> wrote:
>>
>> Joe,
>>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Feb 2020 19:39:16 -0800

> On Feb 27, 2020, at 7:29 PM, Tom Herbert <[email-masked]> wrote:
> 
> than performance for end users. We

You chose a 3-tuple to a 1-tuple tradeoff . There is no tradeoff. One must deliver a 4-tuple. 

My 2 cents,
Dino

---

From: Tom Herbert <[email-masked]>
Date: Thu, 27 Feb 2020 20:07:58 -0800

> You chose a 3-tuple to a 1-tuple tradeoff . There is no tradeoff. One must deliver a 4-tuple.
Sure, but EH insertion has not been shown to be secure, robust, or
interoperable. So this is currently is trading off three critical
requirements for just one (assuming that EH insertion is necessary for
performance which isn't even clear).

Tom

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 27 Feb 2020 20:15:51 -0800

Fernando said:

"If that were the case, anything and everything would be published as an
RFC."

[BA] So you're saying that this is not the case already?

"Among other things, the specs we publish are supposed to be subject to a
decent level of review, and are also supposed to be coherent groups of
specifications."

[BA] Please feel free to design a process that can accomplish this, given
the level of participation we have within the IETF.
The IESG members have a near-impossible job, so they have to rely on
Directorates, who in turn do the best they can. But the IETF process
exercises much of its restraint at the beginning of the process (*before* a
WG is chartered).  Once Chartered, it is rare for a WG document with
sufficient energy behind it to fail to get through the process.  The review
process does not guarantee that drafts conform to BCPs or IAB statements,
let alone consistency with other RFCs.

"If you have one spec that says one thing, and then you have another, from
the same Std Org, that says the opposite, without "obsoleting" the former,
then you end up with something that won't have a single bit of coherence,
virtually impossible to digest by anybody else other by than a limited
group of people that just happens to know how everyone
violates each others specs."

[BA] This has been the case from the earliest days.  For example, as
documented in RFC 4840, back in the early 1980s, there were 3+ approaches
to the encapsulation of IP on Ethernet/IEEE 802.1.  Yet the marketplace
sorted things out then, as they did later when some of the same issues
arose with WiMax/802.16 (RIP).  If there are dueling approaches, it is
often best to document them; rather than relying on standards bodies to
"choose a winner".

---

From: Joseph Touch <[email-masked]>
Date: Thu, 27 Feb 2020 20:27:44 -0800

> On Feb 27, 2020, at 3:54 PM, Mark Andrews <[email-masked]> wrote:
> ...
> Encapsulation doesn’t make the packet larger.

Not strictly; it does make the unit of transfer larger. It’s the tunnel ingress’s job to adapt to that, e.g., using source fragmentation at the ingress.

> It is no different to

We’re talking about the unit of transfer - which does get larger….

> PTB to the original (as far as the encapsulating node is concerned)

No, it really doesn’t. I don’t expect to chop packets into 48 byte units just to go over an ATM “hop” in an IP path. The only party who needs to know about the PTB of a tunnel transit is the tunnel ingress. Again, see draft-intarea-tunnels.

Joe

---

From: Joseph Touch <[email-masked]>
Date: Thu, 27 Feb 2020 20:33:57 -0800

> On Feb 27, 2020, at 3:58 PM, Robert Raszuk <[email-masked]> wrote:
> 
> 

I don’t care about what you WANT to do; I care whether it breaks what everyone else expects.

Any device along an IP path that makes a packet larger IN ANY WAY is ITSELF responsible for making sure that packet can continue forward. At a tunnel, that means work at BOTH the ingress (source fragmentation) and egress (reassembly).

Now, if you add EHs to an IP packet and you’re in control of the ability to do source fragmentation AND reassembly ***IN THE PATH YOU MANAGE***, then you simply can’t do it. Because it WILL break PLPMTUD.

So if you still WANT to do this(1), then YOU need to prove you can CLEAN UP YOUR MESS. Where is the draft that explains how PLPMTUD, among other things, will continue to work?

Joe

(1) this whole thing sounds a lot like Active Nets, which was a retread of SoftNet. So the cycle goes, every 20 years or so. Take the slowest thing a router does and expect it to do more of it, as Jon said. What is it Einstein said about the definition of insanity?

---

From: Joseph Touch <[email-masked]>
Date: Thu, 27 Feb 2020 20:36:29 -0800

> On Feb 27, 2020, at 4:21 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Actually, that's the only thing it ever meant and always will. When addresses change, *by definition*, the*ends* change (and yes, that's what NATs do - they create end-to-end CONTENT transfer over separate end-to-end Internets).
> 

I’d start with RFCs 791 and 1122, but there’s also the pseudo header in RFC 793, to be very specific.

> TCP and TLS give me a reliable end-to-end stream. The fact that the IP address is exposed is merely an unfortunate defect in the legacy APIs. 
> 
> As the application layer designer, I am the customer here. I do not care about the IP address.

Hmmm. By what value do you call  TCP endpoint?

You must have magic sockets that don’t actually refer to IP addresses.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 28 Feb 2020 01:43:54 -0300

> [BA] So you're saying that this is not the case already?

Yes, that's not the case, particularly for people that participate 
independently.

> [BA] Please feel free to design a process that can accomplish this, 
> given the level of participation we have within the IETF.
> exercises much of its restraint at the beginning of the process 
> (*before* a WG is chartered).  Once Chartered, it is rare for a WG 
> document with sufficient energy behind it to fail to get through the 
> process.  The review process does not guarantee that drafts conform to 
> BCPs or IAB statements, let alone consistency with other RFCs.

There's a big difference between a document being published, and the 
authors of a document crafting whatever they please into that document, 
and having the IETF rubberstamp it.

> "If you have one spec that says one thing, and then you have another, 
> documented in RFC 4840, back in the early 1980s, there were 3+ 
> approaches to the encapsulation of IP on Ethernet/IEEE 802.1.  Yet the 
> marketplace sorted things out then, as they did later when some of the 
> same issues arose with WiMax/802.16 (RIP).  If there are dueling 
> approaches, it is often best to document them; rather than relying on 
> standards bodies to "choose a winner".

I'm not referring to competing technologies. I'm talking about one spec 
(e.g. SRv6) blatantly violating another one (IPv6).

When you have conflicting specs, you're kind of at odds with being a 
*standards* organization.... -- nobody knows what to expect, because one 
document says one thing, and another says another thing.

There's a reason for which we have the "Update" and "Obsolete" tags in 
RFCs...

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Fri, 28 Feb 2020 13:35:21 +0700

Dear Fernando &
architecture-discuss,

F. Gont said about proposals regarding with IP(v6) and among others (in the
first message of this thread):

"* On the procedural area:

  + Where/how should IETF WGs seek for architecture-related advice"?

I finded Dave Thaler said in "Evolution of the IP Model" (2009):

"(From the 1978 IEN, the 1980 RFC 760 to the 1981 RFC 7611:) The evolution
didn’t stop there, however, and the IP model has continued to change over
the years to meet new demands. Some of those changes were intentional. Some
were because we found deficiencies. Others were the result of new
capabilities. Often, the changes were a consequence of trying to do
something else.

By 1989, there was already some confusion concerning the IP model. RFC 1122
was written in an effort to clear up some of that confusion as well as to
extend the service model. There are plenty of other RFCs that offered
advice on various specific aspects of the IP model, and as a result, to
gain an understanding of the IP model, one needed to search many RFCs.

Another RFC appeared in 2004, which is probably the one that is closest in
spirit to this work. That one-RFC 3819-offered advice for link-layer
protocol designers on how to minimize the impact on layers above the link
layer. Hence, it dealt with the service model at the bottom of IP, whereas
the present work deals with the service model at the top of IP.

...".
https://www.ietfjournal.org/evolution-of-the-ip-model/

Regard,
Guntur Wiseno Putra

Pada Jumat, 28 Februari 2020, Fernando Gont <[email-masked]> menulis:

> authors of a document crafting whatever they please into that document, and
> having the IETF rubberstamp it.
>
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 09:18:52 +0100

>  I don’t care about what you WANT to do; I care whether it breaks what
everyone else expects.

I see many folks on this colorful thread simply forgot what networks are
for. To deliver packets in the most robust and resilient way to end user
applications.

As links and node fails there is established need to quickly repair when
the failure occurs to minimize packet loss.

I see that even among "routing experts" there is still false believe that
when a failure happens let's crunk up OSPF or ISIS or BGP to repair control
plane end to end to go around broken link or node. They call it "network
convergence".

In the same time for over 20 years now it has been well established that
above model is wrong approach to fast repair. Repair must happen at the
point of failure or just next to it. The terminology we use to describe
this in contrast to network convergence is connectivity restoration. With
that network protocols do not need to be stressed any more and they can
take as much time (in realistic scale) as they need to converge while user
packets bypass the failure.

And to accomplish such model in a loop free fashion *bits are added on the
fly to the packets. *If operator would do it in a way that end users suffer
he will loose revenue or job. So this is not IETF business to say - no you
can not do it as it may sometimes fail say due to MTU. If ingress to ones
network is 4K and his network can carry 9K MTU - the issues would never
cause any problems during said repair.

Sometimes bits are added in a form of new MPLS label(s) MPLS-FRR, sometimes
in a form of new encapsulation IP-FRR. Here while we are at the SR debate
such addition can be something in between. That is in my view enhancement
of IPv6 to make it more attractive to be deployed and used. I find it very
surprising that those who should promote the technology the most are
spending hours to make it less attractive for real life use.

- - -

As stated in the other thread I think SR folks were just trying to be good
IETF citizens and went towards the path of IPv6 "extension". I would just
go as building on prior art approach without even talking to 6man WG :)

Kind regards,
R.

On Fri, Feb 28, 2020 at 5:34 AM Joseph Touch <[email-masked]> wrote:

> > That removal as it has been explained to you many times happens at the
> node which is explicitly listed as DA of the packet.
> >
> plane for end users with 10s of ms of connectivity restoration times upon
> failure or keeping original IPv6 dogmas in place where folks never
> Any device along an IP path that makes a packet larger IN ANY WAY is
> ITSELF responsible for making sure that packet can continue forward. At a
> tunnel, that means work at BOTH the ingress (source fragmentation) and
> egress (reassembly).
>
> Now, if you add EHs to an IP packet and you’re in control of the ability
> to do source fragmentation AND reassembly ***IN THE PATH YOU MANAGE***,
> then you simply can’t do it. Because it WILL break PLPMTUD.
>
> So if you still WANT to do this(1), then YOU need to prove you can CLEAN
> UP YOUR MESS. Where is the draft that explains how PLPMTUD, among other
> things, will continue to work?
>
> Joe
>
> (1) this whole thing sounds a lot like Active Nets, which was a retread of
> SoftNet. So the cycle goes, every 20 years or so. Take the slowest thing a
> router does and expect it to do more of it, as Jon said. What is it
> Einstein said about the definition of insanity?
>
>

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Fri, 28 Feb 2020 16:02:06 +0700

Dear Fernando, Robert &
architecture-discuss,

Change & Architectural Thinking and Planning...:

To add what was about D. Thaler's regarding with "proposals and changes"
and R. Raszuk's "technology for real life uses", there are also

P. Nikander in "Reflections on Architecture" (2005) proposed

"What we perhaps don’t consider very often is the fact that there are huge
asset values embedded in various parts of the network.

Any change requires a reason to overcome the associated hurdle.
Consequently, I have found it very instructive to try to think about the
network and protocols in terms of assets, incentives, costs, and benefits".

Nikander said that there are different types and sources of complexity as
it is represented in the Internet system: emergent complexity &
architectural complexity. "While we can at most work towards understanding
emergent complexity in the first place, there is a great deal we can do
about architectural complexity." And, he said, here we need visions.

https://www.ietfjournal.org/reflections-on-architecture/#

When technology is about human passions for beauty: By a second reading on
Heidegger's via Boris Groys ("Art, Technology and Humanity, 2017), there is
an understanding that "changes of/in technology" is made/engineered
"precisely to immunize man against change, to liberate man from his
dependency on physis, on fate, on accident."

https://www.e-flux.com/journal/82/127763/art-technology-and-humanism/

Regard,
Guntur Wiseno Putra

Pada Jumat, 28 Februari 2020, Robert Raszuk <[email-masked]> menulis:

> And to accomplish such model in a loop free fashion *bits are added on
> the fly to the packets. *If operator would do it in a way that end users
> suffer he will loose revenue or job. So this is not IETF business to say -
> no you can not do it as it may sometimes fail say due to MTU. If ingress to
> ones network is 4K and his network can carry 9K MTU - the issues would
> never cause any problems during said repair.
>
> Sometimes bits are added in a form of new MPLS label(s) MPLS-FRR,
> sometimes in a form of new encapsulation IP-FRR. Here while we are at the
> SR debate such addition can be something in between. That is in my view
> enhancement of IPv6 to make it more attractive to be deployed and used. I
> find it very surprising that those who should promote the technology the
> most are spending hours to make it less attractive for real life use.
>
> - - -
>
>> (1) this whole thing sounds a lot like Active Nets, which was a retread
>> of SoftNet. So the cycle goes, every 20 years or so. Take the slowest thing
>> a router does and expect it to do more of it, as Jon said. What is it

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 28 Feb 2020 08:31:55 -0500

> You must have magic sockets that don’t actually refer to IP addresses.

I have a library that implements RFC6763. So my application code doesn't
actually consider IP addresses.

Since the platform doesn't provide real DNS resolution, I have to write my
own of course. And I will be putting DNSSEC in there at some point
probably. But it is a feature set that should be in the platform.

At some point, I am going to have to look at implementing TURN/STUN/PCP
etc. for NAT traversal. That certainly isn't application layer code.

So as far as i am concerned, I am resolving a triple of SRV prefix, DNS
name and account name to a socket.

The only case in which my application code would deal in a raw IP address
and port is if the resolution is delegated to an external presence service.
If Alice is trying to make a person-person call to Bob, we may want to
route the packets direct. So there has to be some sort of presence service
in the cloud to set up the connection which is going to end up telling one
of them to place a call for an IP address/port and the other of them to
listen for the incoming.

The test of this design is straightforward, all the proposals for DNS
privacy etc. sit inside the library. I can drop out regular client DNS for
DPRIV. Or I can use my omnibroker version which makes use of the RFC6763
interface.

Abstracting away from TLS and UDP means I can adapt to new transports like
QUIC very easily. For certain types of message, I have my own UDP based
transport. Most cryptographic service transactions consist of a single
request packet followed by one to a dozen response packets. That sits in
the same box.

It really isn't 'magic', it is just understanding that this is platform
code not application code.

We do not have 'layers' in the Internet architecture but we have modules
that we call layers. And those layers have interfaces to the layers above
and beneath them that are mediated by a naming infrastructure. And we
should be really explicit about what those interfaces are because they have
to be stable over long periods of time.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 28 Feb 2020 08:14:39 -0800

On Fri, Feb 28, 2020 at 5:32 AM Phillip Hallam-Baker
<[email-masked]> wrote:
> I have a library that implements RFC6763. So my application code doesn't actually consider IP addresses.
>
It's great that _you_ have a solution, but not everyone does. The
standard says that a TCP connection endpoint is defined by a 4-tuple
of source address, destination address, source port, destination port.
It is an invariant that we have forty years of operational experience
with. If you think that design decision is obsolete or should be
revisited, then by all means propose an alternative in tsvwg.

Tom

> Since the platform doesn't provide real DNS resolution, I have to write my own of course. And I will be putting DNSSEC in there at some point probably. But it is a feature set that should be in the platform.
>
> At some point, I am going to have to look at implementing TURN/STUN/PCP etc. for NAT traversal. That certainly isn't application layer code.
>
> So as far as i am concerned, I am resolving a triple of SRV prefix, DNS name and account name to a socket.
>
> The only case in which my application code would deal in a raw IP address and port is if the resolution is delegated to an external presence service. If Alice is trying to make a person-person call to Bob, we may want to route the packets direct. So there has to be some sort of presence service in the cloud to set up the connection which is going to end up telling one of them to place a call for an IP address/port and the other of them to listen for the incoming.
>
>
> The test of this design is straightforward, all the proposals for DNS privacy etc. sit inside the library. I can drop out regular client DNS for DPRIV. Or I can use my omnibroker version which makes use of the RFC6763 interface.
>
> Abstracting away from TLS and UDP means I can adapt to new transports like QUIC very easily. For certain types of message, I have my own UDP based transport. Most cryptographic service transactions consist of a single request packet followed by one to a dozen response packets. That sits in the same box.
>
>
> It really isn't 'magic', it is just understanding that this is platform code not application code.
>
> We do not have 'layers' in the Internet architecture but we have modules that we call layers. And those layers have interfaces to the layers above and beneath them that are mediated by a naming infrastructure. And we should be really explicit about what those interfaces are because they have to be stable over long periods of time.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 28 Feb 2020 12:19:48 -0500

> revisited, then by all means propose an alternative in tsvwg.

That is a TCP connection. Applications don't deal in TCP connections, they
deal in sockets.

Its called abstraction. All that complexity belongs in a box that the
application programmer doesn't need to open.

Now current practice is that people use the gethostbyname() call to do DNS
resolution and so they end up being unable to make use of DNS properly. But
that is a problem with the 40 year old legacy API which can be changed or
circumvented entirely

RFC6763 is what the application layer should use.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 28 Feb 2020 10:12:05 -0800

On Fri, Feb 28, 2020 at 9:20 AM Phillip Hallam-Baker
<[email-masked]> wrote:
> That is a TCP connection. Applications don't deal in TCP connections, they deal in sockets.
>
> Its called abstraction. All that complexity belongs in a box that the application programmer doesn't need to open.
>
Yes, but in BSD sockets, the most common networking API, "bind" takes
an address and port number argument, "connect" takes and address and
port number argument, getsockname and getpeername return the
respective pairs set on a socket. So the TCP 4-tuple is very visible
to applications and has been for many years. If there's a better way
to do this that hides this and makes it easier I say go for it, but
please don't call this a solved problem until you've achieved
ubiquitous deployment and we can obsolete the sockets API since no one
is using it anymore.

In any case, I don't see how any of this is relevant to protocol
discussion. We build APIs based on protocol requirements, not the
other way around.

Tom
> Now current practice is that people use the gethostbyname() call to do DNS resolution and so they end up being unable to make use of DNS properly. But that is a problem with the 40 year old legacy API which can be changed or circumvented entirely
>

---

From: Joseph Touch <[email-masked]>
Date: Fri, 28 Feb 2020 17:55:36 -0800

> On Feb 28, 2020, at 12:18 AM, Robert Raszuk <[email-masked]> wrote:
> 
> I see many folks on this colorful thread simply forgot what networks are for. To deliver packets in the most robust and resilient way to end user applications. 

They’re for delivering packets, agreed.

I did look at the protocols involved here; the ingress does add headers but doesn’t appear to handle fragmentation.

That’s a non-starter if you want your packets to traverse a network because people WILL hand you 1280-byte packets, so what will you do?

Joe

---

From: Joseph Touch <[email-masked]>
Date: Fri, 28 Feb 2020 17:57:15 -0800

> On Feb 28, 2020, at 5:31 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 

Something does. I’m not aware of a network that uses DNS FQDNs as endpoint addresses or that can open a socket without ultimately using an IP address.

Just because you don’t see it doesn’t mean it isn’t how your system actually works.

Joe

---

From: Andrew Alston <[email-masked]>
Date: Sun, 1 Mar 2020 01:30:01 +0000

Guntur,

I have to say – I sat and thought about what you wrote here – and there was one line tha really struck in in the context of this whole debate

<snip>
> Any change requires a reason to overcome the associated hurdle. Consequently, I have found it very instructive to try to think about the network and protocols in terms of assets, incentives, costs, and benefits".

On this – we are in total agreement – which is why when I look at what has occurred in SPRING – I find myself getting very depressed.

In order to consider protocols and change in the context of the four criteria you listed – we would need certain information –

  1.  Why do the authors of the disputed draft insist on holding with PSP – what is the substantive use case – I for one – do not believe this has been close to addressed in light of the fact that there were no less than 4 ways to progress the contentious draft (compromises were offered, everything from, progress the draft with this moved to another document that could be debated, to update the rfc8200) – in every case – the authors refused to budge
  2.  In order to evaluate benefit you need people who are prepared to state the benefit they see in something – instead we have a document advancing based not on consensus but on (and I quote) “We had to move this forward” and citing a bunch of people who +1’ed a list in what was in my view a clearly orchestrated +1 campaign as justification for support.  I’ll be releasing a rather interesting summary from the lists showing just how many times the majority of those people have *ever* posted to the lists before – it makes for an interesting read.
  3.  With regards to the costs – without knowing what the real reason for insisting on holding to this – and there must be done considering the dogged way the authors and the vendor behind this document have insisted on it – without giving proper reasons – this cannot be evaluated.

So – on the basis of the criteria you listed alone – the fact that we are seeing something being railed through a working group – despite substantive – numerous – and unaddressed objections in total violation of the very concept of consensus – disturbs me greatly.  I have always believed that if things like appeals can be avoided – that is always first prize – sadly in this case – we are now forced into an appeal process and we will see how it plays out – but – in light of all this – I can understand why people on so many lists are questioning what is going on.

Thanks

Andrew

---

From: Fernando Gont <[email-masked]>
Date: Sat, 29 Feb 2020 22:46:03 -0300

On 28/2/20 22:55, Joseph Touch wrote:
> 
> 
>> On Feb 28, 2020, at 12:18 AM, Robert Raszuk <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> I see many folks on this colorful thread simply forgot what networks 
>> are for. To deliver packets in the most robust and resilient way to 
>> end user applications. 
> 
> I did look at the protocols involved here; the ingress does add headers 
> but doesn’t appear to handle fragmentation.
> 
> That’s a non-starter if you want your packets to traverse a network 
> because people WILL hand you 1280-byte packets, so what will you do?

FWIW, we have been insisting on this point (and others) since they first 
tried to push EH insertion in draft-ietf-6man-segment-routing-header.

THey removed it from *that* document, but they keep trying to push 
similar ideas in other documents.

---

From: Joseph Touch <[email-masked]>
Date: Sat, 29 Feb 2020 18:19:55 -0800

> On Feb 29, 2020, at 5:46 PM, Fernando Gont <[email-masked]> wrote:
> 
> FWIW, we have been insisting on this point (and others) since they first tried to push EH insertion in draft-ietf-6man-segment-routing-header.
> 
> THey removed it from *that* document, but they keep trying to push similar ideas in other documents.

Well its seems simple to me - they need a plan for fragmentation or it’s simply a nonstarter because they can’t support 1280-B packets traversing the network.

No amount of “but this is what the user wants” translates to “they want their packets dropped silently”.

Joe

---

From: Andrew Alston <[email-masked]>
Date: Sun, 1 Mar 2020 02:27:02 +0000

I raised the issue of the limitations imposed by RFC 7112 during the course of this saga – it’s on the list of things that were bluntly and shamelessly ignored without a single comment before this document mysteriously was declared to be moving forward out of last call on the basis of some +1’s.

Thanks

Andrew

From: ietf <[email-masked]> on behalf of Joseph Touch <[email-masked]>
Date: Sunday, 1 March 2020 at 05:21
To: Fernando Gont <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Internet Architecture Board <[email-masked]>, Internet Area <[email-masked]>, IETF <[email-masked]>
Subject: Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On Feb 29, 2020, at 5:46 PM, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 29 Feb 2020 23:44:43 -0300

On 29/2/20 23:19, Joseph Touch wrote:
>>> I did look at the protocols involved here; the ingress does add 
>>> headers but doesn’t appear to handle fragmentation.
>> FWIW, we have been insisting on this point (and others) since they 
>> first tried to push EH insertion in 
>> draft-ietf-6man-segment-routing-header.
>>
> Well its seems simple to me - they need a plan for fragmentation or it’s 
> simply a nonstarter because they can’t support 1280-B packets traversing 
> the network.

Indeed.

But it's worse than that. The proponents, and others, claim that IPv6 
supports extension header insertion/removal en-route to a destination.

In order for that to be the case, the IPv6 specification itself 
(RFC8200) would have a plan to make PMTUD work (and IPsec AH, too). But 
obviously it doesn't (because it never supporte EH insertion/removal 
en-route to destination).

Still, the errata I submitted 
(https://www.rfc-editor.org/errata/eid5933), is unprocessed, and at 
least there was a statement that would be "held for document update" 
(see: 
https://mailarchive.ietf.org/arch/msg/ipv6/yVKxBF3VnJQkIRuM8lgWN4_G3-o/)

> their packets dropped silently”.

It smells even worse when they pretend that the IPv6 allows for their 
proposed behavior.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 29 Feb 2020 23:49:36 -0300

On 27/2/20 20:04, Robert Raszuk wrote:
> Joe, all,
> 
> Just to clarify something Fernando purposely missed in his call for action: >
> All operations on the packets discussed in SPRING WG are happening NOT 
> on the original (end to end) packet header. They are all defined to 
> happen within new imposed outer encapsulated header (IPv6 in IPv6 to be 
> precise).

Nobody ever claimed something different.

But I tell you what: the outer packets are IPv6 packets. Hence, when you 
add/remove extension headers en-route to destination, you are violating 
RFC8200.

Please repeat with me: IPv6 does not allow the insertion/removal of 
extension header while the packets are en-route to the final destination.

I wished this conversation could go back to a honest one.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 29 Feb 2020 23:57:44 -0300

> listed in DA of the packet).

That is obviously a lie.

PSP happens en-route.  Isn't it obvious from the fact that "PSP" stands 
for "PENULTIMATE Segment Pop"? It's done at the last waypoint on the way 
to the final destination of the packet.

The same is true for the TI-LFA behavior with you moved out to a 
different document: it causes an extension header to be inserted in IPv6 
packets while en-route to the final destination 
(https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa).

It is quite curious the mode in which the proponents of this behavior, 
and even more that consensus has been claimed on this document.

I'm glad that there are more eyes now looking at what's going on.

Thanks,

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Sun, 1 Mar 2020 10:10:06 +0700

Dear Andrew &
architecture-discuss,

I struggled to read yours, Andrew, and others mentioned in this message.

What are about the 4 criteria (assets, incentives, costs and benefits)
mentioned by Pikander...?

He mentioned about "vision" following the criteria:

" We need some kind of an architectural vision and a related transition
path; an idea of where we are heading and perhaps how we could get there.

...".

"Vision is a coincidence between what are Pikander's on the Internet
Architecture (especially about protocols and changes) and what is
Heidegger's on art, technology and humanity:

He ... (Heidegger)... believes this because, as he explains in his earlier
text “The Origin of the Work of Art,” art is nothing other than the
revelation of the way we use things—and, if one wants, of the way we are
used by things.2 Here it is important to note that for Heidegger, the
artwork is not a thing but a vision that opens to the artist in the
clearing of Being.

More generally, the "vision" to elaborate concerns with developing the
Internet technology research and standards: L. Daigle (2009) said

"(In developing the Internet technology based on innivation and
interoprability:) In that model of development, there are three key types
of activity from which feedback needs to be fostered: (1) development of
technical specifications, (2) deployment, and (3) answering open questions
(research). The IETF focuses primarily on the first activity, but it has a
close relationship with the third in the shape of the Internet Research
Task Force (IRTF). The IETF process itself is deliberately open to and
seeking feedback from the second activity: deployment experiences".

https://www.ietfjournal.org/developing-internet-technology-
research-and-standards/

More recently about the "vision" to elaborate is section 4. How We See the
Internet of 2019 ISOC GlobalbReport "Consolidation in the Internet Economy"

https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf

Regard,
Guntur Wiseno Putra

Pada Minggu, 01 Maret 2020, Andrew Alston <[email-masked]>
menulis:

> Guntur,
>
>
>
> I have to say – I sat and thought about what you wrote here – and there
> was one line tha really struck in in the context of this whole debate
>
>
>
> <snip>
>
> On this – we are in total agreement – which is why when I look at what has
> occurred in SPRING – I find myself getting very depressed.
>
>
>
> In order to consider protocols and change in the context of the four
> criteria you listed – we would need certain information –
>
>
>
>    1. Why do the authors of the disputed draft insist on holding with PSP
>    – what is the substantive use case – I for one – do not believe this has
>    been close to addressed in light of the fact that there were no less than 4
>    ways to progress the contentious draft (compromises were offered,
>    everything from, progress the draft with this moved to another document
>    that could be debated, to update the rfc8200) – in every case – the authors
>    refused to budge
>    2. In order to evaluate benefit you need people who are prepared to
>    state the benefit they see in something – instead we have a document
>    advancing based not on consensus but on (and I quote) “We had to move this
>    forward” and citing a bunch of people who +1’ed a list in what was in my
>    view a clearly orchestrated +1 campaign as justification for support.  I’ll
>    be releasing a rather interesting summary from the lists showing just how
>    many times the majority of those people have **ever** posted to the
>    lists before – it makes for an interesting read.
>    3. With regards to the costs – without knowing what the real reason
>    for insisting on holding to this – and there must be done considering the
>    dogged way the authors and the vendor behind this document have insisted on
>    it – without giving proper reasons – this cannot be evaluated.
>
>
>
> So – on the basis of the criteria you listed alone – the fact that we are
> seeing something being railed through a working group – despite substantive
> – numerous – and unaddressed objections in total violation of the very
> concept of consensus – disturbs me greatly.  I have always believed that if
> things like appeals can be avoided – that is always first prize – sadly in
> this case – we are now forced into an appeal process and we will see how it
> plays out – but – in light of all this – I can understand why people on so
> many lists are questioning what is going on.
>
>
>
> Thanks
>
>
>
> Andrew
>