Re: [Int-area] ICMP extension for node ID updated [draft-fenner-intarea-extended-icmp-hostid-01]

[Brian E Carpenter]

Thanks Bill. I'd still appreciate opinions whether 6man should define the RFC 4007 zone identifier 
more precisely than just calling it a "string". In practice it's the same as what 
operating systems call an "interface name", so the text of RFC 5837 and 2863 is of 
interest.

Regards
   Brian Carpenter

On 27-Apr-24 07:27, Bill Fenner wrote:

Hi Brian,

What you've ended up finding here is that I copied and pasted some text and missed making 
some edits to it.  The "interface" wording is in rfc5837 (which I'm not 
updating, just copying from) and this text is all supposed to be about a *node* name / 
hostname.

https://author-tools.ietf.org/api/iddiff?doc_1=draft-fenner-intarea-extended-icmp-hostid_2=https://fenner.github.io/icmp-node-id/draft-fenner-intarea-extended-icmp-hostid.txt
 
<https://author-tools.ietf.org/api/iddiff?doc_1=draft-fenner-intarea-extended-icmp-hostid_2=https://fenner.github.io/icmp-node-id/draft-fenner-intarea-extended-icmp-hostid.txt>
 shows the diff that I've made - so this document no longer talks about interface names 
except in the references to rfc5837.

   Bill



On Wed, Apr 24, 2024 at 6:41 PM Brian E Carpenter mailto:brian.e.carpen...@gmail.com>> wrote:

Bill, et al,

Re:
"The interface name MUST be represented in the UTF-8 charset [RFC3629] using the 
Default Language [RFC2277]."

draft-carpenter-6man-zone-ui is wending its way in 6man, and it's been suggested that 
we should clarify the allowed character set for RFC4007 zone identifiers, which are in 
practice interface names. At the moment, RFC4007 simply says they are "strings" 
without signficant qualification.

For example, "Ethernet1/1-George.sjc" would be a completely legal zone identifier 
under RFC4007. As has also been observed, so would "blåbærsyltetøy0/0/0".

Opinions welcome, here or on 6man. Consistency of the two drafts seems 
desirable.

Regards
     Brian Carpenter

On 25-Apr-24 12:16, Bill Fenner wrote:
 > Hi all,
 >
 > I've updated the node ID ICMP extension draft that I presented in 
intarea in Brisbane.  The motivation for this work is that we got a request from a 
customer to append the hostname to the interface name field in the RFC5837 
response, e.g.,
 >
 > 2  10.2.2.3  11.322 
ms
 >
 > and I thought it was more productive to create a standard way to encode 
the hostname in the message itself.
 >
 > The change from the -00 document is that on a suggestion from Reji 
Thomas, I've made the packet format a strict subset of that in RFC5837.  Since 
this data is intended for presentation to users, this is useful since one doesn't 
have to write a whole new TLV parser; one can reuse the one that already exists 
for RFC5837 and just change the user-visible output.
 >
 > Sample hop output from traceroute with this additional info printed as 
"NODE":
 >
 > 2  10.2.2.3 
 11.322 
ms
 >
 > This represents an RFC5837 "incoming interface" info record with ifIndex 
99, incoming address 10.10.2.3, etc., and a node ID IP address 2001:db8::137f.  In this 
example the IPv4 addresses are private, but the node ID IP address can be a global IPv6 
address.
 >
 > The IANA has assigned Class-Num 5 to this document.
 >
 > Your feedback on this idea is most welcome.
 >
 > Name:     draft-fenner-intarea-extended-icmp-hostid
 > Revision: 01
 > Title:    Extending ICMP for Node Identification
 > Date:     2024-04-23
 > Group:    Individual Submission
 > Pages:    9
 > URL: https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.txt 
<https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.txt> 
<https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.txt 
<https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.txt>>
 > Status: https://datatracker.ietf.org/doc/draft-fenner-intarea-extended-icmp-hostid/ 
<https://datatracker.ietf.org/doc/draft-fenner-intarea-extended-icmp-hostid/> 
<https://datatracker.ietf.org/doc/draft-fenner-intarea-extended-icmp-hostid/ 
<https://datatracker.ietf.org/doc/draft-fenner-intarea-extended-icmp-hostid/>>
 > HTML: https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.html 
<https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.html> 
<https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.html 
<https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.html>>
 > HTMLized: https://datatracker.ietf.org/doc/html/draft-fenner-intarea-extended-icmp-hostid 
<https://datatracker.ietf.org/doc/html/draft-fenner-intarea-extended-icmp-h

Re: [Int-area] ICMP extension for node ID updated [draft-fenner-intarea-extended-icmp-hostid-01]

[Brian E Carpenter]

Bill, et al,

Re:
"The interface name MUST be represented in the UTF-8 charset [RFC3629] using the 
Default Language [RFC2277]."

draft-carpenter-6man-zone-ui is wending its way in 6man, and it's been suggested that we 
should clarify the allowed character set for RFC4007 zone identifiers, which are in 
practice interface names. At the moment, RFC4007 simply says they are "strings" 
without signficant qualification.

For example, "Ethernet1/1-George.sjc" would be a completely legal zone identifier under 
RFC4007. As has also been observed, so would "blåbærsyltetøy0/0/0".

Opinions welcome, here or on 6man. Consistency of the two drafts seems 
desirable.

Regards
   Brian Carpenter

On 25-Apr-24 12:16, Bill Fenner wrote:

Hi all,

I've updated the node ID ICMP extension draft that I presented in intarea in 
Brisbane.  The motivation for this work is that we got a request from a 
customer to append the hostname to the interface name field in the RFC5837 
response, e.g.,

2  10.2.2.3  11.322 ms

and I thought it was more productive to create a standard way to encode the 
hostname in the message itself.

The change from the -00 document is that on a suggestion from Reji Thomas, I've 
made the packet format a strict subset of that in RFC5837.  Since this data is 
intended for presentation to users, this is useful since one doesn't have to 
write a whole new TLV parser; one can reuse the one that already exists for 
RFC5837 and just change the user-visible output.

Sample hop output from traceroute with this additional info printed as "NODE":

2  10.2.2.3 
 
11.322 ms

This represents an RFC5837 "incoming interface" info record with ifIndex 99, 
incoming address 10.10.2.3, etc., and a node ID IP address 2001:db8::137f.  In this 
example the IPv4 addresses are private, but the node ID IP address can be a global IPv6 
address.

The IANA has assigned Class-Num 5 to this document.

Your feedback on this idea is most welcome.

Name:     draft-fenner-intarea-extended-icmp-hostid
Revision: 01
Title:    Extending ICMP for Node Identification
Date:     2024-04-23
Group:    Individual Submission
Pages:    9
URL: https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.txt 

Status: https://datatracker.ietf.org/doc/draft-fenner-intarea-extended-icmp-hostid/ 

HTML: 
https://www.ietf.org/archive/id/draft-fenner-intarea-extended-icmp-hostid-01.html 

HTMLized: 
https://datatracker.ietf.org/doc/html/draft-fenner-intarea-extended-icmp-hostid 

Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-fenner-intarea-extended-icmp-hostid-01
 


Abstract:

    RFC5837 describes a mechanism for Extending ICMP for Interface and
    Next-Hop Identification, which allows providing additional
    information in an ICMP error that helps identify interfaces
    participating in the path.  This is especially useful in environments
    where each interface may not have a unique IP address to respond to,
    e.g., a traceroute.

    This document introduces a similar ICMP extension for Node
    Identification.  It allows providing a unique IP address and/or a
    textual name for the node, in the case where each node may not have a
    unique IP address (e.g., the IPv6 nexthop deployment case described
    in draft-chroboczek-intarea-v4-via-v6).

Thanks,
   Bill


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

[Brian E Carpenter]

On 23-Mar-24 03:40, Robinson, Herbie wrote:

Legitimate reasons for a middle box to look at transport headers:

Firewalls need to look at port numbers to perform their quite necessary job.


Steve Bellovin pointed out in 1999 that such firewalls should be in the 
destination host**. That works very well, and in particular it scales perfectly 
in proportion to the number of hosts in the Internet, so doesn't need hardware 
assist.

Firewall vendors don't agree and never have done.

Unfortunately for Tom's argument, firewalls at enterprise network boundaries 
are widespread and hosts without adequate self-protection are common. It's a 
sad state of affairs. It will be interesting to see whether QUIC manages to 
effect change.

** https://www.cs.columbia.edu/~smb/papers/distfw.pdf

   Brian



Anything forwarding packets (including NICs) needs to make sure TCP packets for 
a given IP/port/IP/port go through the same path to avoid re-ordering.

Note that firewalls usually have a hardware assisted fast path and a software 
based slow path.  Any new protocol features will kick packets into the slow 
path until the hardware gets updated (and that’s if the hardware gets updated).

--

Hello,

Interestingly, there is a similar discussion going on in Spring around the 
C-SID draft, about whether people think it is legitimate for intermediate nodes 
to be able to parse / process / check information that are supposed to be used 
by end nodes or not. This goes with checksum, port numbers, segment IDs, etc.

I think that acknowledging the possibility for middleboxes to look at and 
modify fields that are supposed to be looked at and checked by end nodes is an 
issue, and breaks fundamental end to end assumptions that are foundational in 
the Internet design. Thus, I think we should allow shim headers (you can name 
them IPv4 extension headers if you want) to be deployed between IPv4 header and 
Transport layer protocol, provided they get a proper protocol number. Of 
course, this will break the operation of middleboxes that try to look at 
information in transport headers, but they should not look at those information 
in the first place, or at least do it in a robust way.

Best regards,

Antoine

*From:* Int-area mailto:int-area-boun...@ietf.org>> 
*On Behalf Of *Tom Herbert
*Sent:* vendredi 22 mars 2024 04:49
*To:* Joe Touch mailto:to...@strayalpha.com>>
*Cc:* Toerless Eckert mailto:t...@cs.fau.de>>; int-area 
mailto:int-area@ietf.org>>
*Subject:* Re: [Int-area] New Version Notification for 
draft-herbert-ipv4-eh-03.txt

On Thu, Mar 21, 2024, 8:28 PM to...@strayalpha.com  
mailto:to...@strayalpha.com>> wrote:



You’ve just described a transport protocol that the intermediate 
nodes know.

Joe,

A transport protocol doesn't meet the requirements. They don't work 
with any transport protocol other than themselves,

They do when you define them that way, i.e., “here’s a transport protocol 
header A, after which you can use any transport protocol, as indicated in field 
X”.

and intermediate nodes cannot robustly parse transport headers

They can’t parse these either. But, if upgraded to do so for headers “A”, 
as per above.

This has to be L3 protocol.

It’s not. It’s L4, or at least that’s what it is* to IP.

Joe,

Please give one concrete example of a transport protocol explicitly designed to 
be processed and modified by intermediate nodes. If you say TCP as in modifying 
port numbers for NAT, I'll point out it that the TCP was never designed for 
this, it breaks TCP Auth option, and QUIC closed this architectural aberration 
by encrypting the transport layer so that intermediate nodes can't muck with it 
:-)

IMO, network nodes have no business participating in transport layer, doing so 
has led to a lot of protocol ossification.

Tom

IPv6 can call them extensions because all IPv6 nodes already know what to 
do with them, even for codepoints they’ve 

Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

[Brian E Carpenter]

On 22-Mar-24 09:04, Tom Herbert wrote:

On Thu, Mar 21, 2024 at 12:46 PM Templin (US), Fred L
 wrote:


Brian,


Why should the IETF spend effort on upgrading IPv4 capabilities at this point?


For air/land/sea/space mobile Internetworking, we expect to engage steady-state 
IP
fragmentation over some paths, but IPv4 will still be in the picture for a long 
time to
come and IPv4 fragmentation has known limitations (e.g., RFC4963). IPv4 
fragmentation
using the IPv6 Fragment Header (adapted for IPv4) would address many of the 
issues.

This is just to name one example. Another example is adapting IPv6 HBH options 
to
carry IP parcels and Advanced Jumbos in IPv4 packets for operation over networks
where IPv4 will still be used for the long term.

IPv4 is going to be around for a long time in many networks, so making it work
more like IPv6 seems like a useful improvement.


Yes, we still have IPv4 users that need the capabilities. If everyone
were on IPv6 we wouldn't need this.


So this proposal hinders IPv6 adoption. I think it would lead to an
"interesting" IETF Last Call discussion.



To be a little more direct, one purpose of the draft is to nullify a
persistent argument against using extension headers: "They don't work
with IPv4".


I was told in Seattle in March 1994 that the Internet was opaque to
new IPv4 options - that's the main reason I stopped work on
https://datatracker.ietf.org/doc/draft-carpenter-aeiou/, in fact.
I understand that you've bypassed that problem in the ipv4-eh
design, but surely the deployment problem here will be worse than
it is for IPv6 extension headers - IPv4 middleboxes and firewalls
are much more widely deployed than they were in 1994.


We've seen the same story play out in a number of proposals. It goes
like this: "We want to annotate packets with ancillary network layer
information like extension headers are designed for, but we still have
a large number of users still on IPv4 and so using extension headers
is a showstopper." Unfortunately, all the alternatives for getting
similar functionality in IPv4 have proven to be essentially hacks
(like having intermediate devices parse UDP payloads, or somehow use
VLAN as metadata and turn Ethernet into an E2E protocol). And of
course, IP options are "not an option"...


Right. But there you've implicitly accepted the limited domain
model, which many in the IETF consider heresy.

   Brian



Tom



Fred


-Original Message-----
From: Int-area  On Behalf Of Brian E Carpenter
Sent: Thursday, March 21, 2024 11:59 AM
To: int-area@ietf.org
Subject: Re: [Int-area] [EXTERNAL] Re: New Version Notification for 
draft-herbert-ipv4-eh-03.txt

EXT email: be mindful of links/attachments.



On 22-Mar-24 03:53, Robinson, Herbie wrote:

I would say that, in theory, that’s not a show stopper, but in practice it is a 
lot of work to implement – enough to suggest that you

wouldn’t get enough implementations to make it useable.

I'll say it because nobody else has (recently).

Why should the IETF spend effort on upgrading IPv4 capabilities at this point?

 Brian



*From:* Int-area  *On Behalf Of *to...@strayalpha.com
*Sent:* Thursday, March 21, 2024 10:46 AM
*To:* Toerless Eckert 
*Cc:* int-area 
*Subject:* [EXTERNAL] Re: [Int-area] New Version Notification for 
draft-herbert-ipv4-eh-03.txt

*[**EXTERNAL SENDER**: This email originated from outside of Stratus 
Technologies. Do not click links or open attachments unless you

recognize the sender and know the content is safe.]***


---

--
--
--
--
---


On Mar 20, 2024, at 9:35 PM, Toerless Eckert mailto:t...@cs.fau.de>> wrote:

 On Wed, Mar 20, 2024 at 09:20:24PM -0700, Tom Herbert wrote:

 In other words, Destination Option Headers do not have 
fundamentally distinct
 processing requirements on the destination host examining it than 
any other
 possible protocol header (e.g.: UDP, TCP), or at least we could 
not find such a description
  

Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-herbert-ipv4-eh-03.txt

[Brian E Carpenter]

On 22-Mar-24 03:53, Robinson, Herbie wrote:

I would say that, in theory, that’s not a show stopper, but in practice it is a 
lot of work to implement – enough to suggest that you wouldn’t get enough 
implementations to make it useable.


I'll say it because nobody else has (recently).

Why should the IETF spend effort on upgrading IPv4 capabilities at this point?

   Brian



*From:* Int-area  *On Behalf Of *to...@strayalpha.com
*Sent:* Thursday, March 21, 2024 10:46 AM
*To:* Toerless Eckert 
*Cc:* int-area 
*Subject:* [EXTERNAL] Re: [Int-area] New Version Notification for 
draft-herbert-ipv4-eh-03.txt

*[**EXTERNAL SENDER**: This email originated from outside of Stratus 
Technologies. Do not click links or open attachments unless you recognize the 
sender and know the content is safe.]***

--

On Mar 20, 2024, at 9:35 PM, Toerless Eckert mailto:t...@cs.fau.de>> wrote:

On Wed, Mar 20, 2024 at 09:20:24PM -0700, Tom Herbert wrote:

In other words, Destination Option Headers do not have 
fundamentally distinct
processing requirements on the destination host examining it than 
any other
possible protocol header (e.g.: UDP, TCP), or at least we could not 
find such a description
for any such guiding rules or treatment differences in RFC8200.


Yes, that's mostly how all the IP protocols are implemented.
Processing of an encapsulated  protocol isn't completely independent,
for instance the pseudo header for the TCP and UDP checksum is
different for IPv4 and IPv6.


Right. But it seems unrelated to whether or not a header is an extension 
header,
TCP and UDP not being extension headers for example.

I haven’t seen it mentioned yet (apologies if so), but there is a big 
difference between extension headers and encapsulated protocols.

Extension headers - no matter how many - can each refer back to the base 
header. Same for the first encapsulated protocol.

E.g.:

IP1 IP2 IP3 TCP….TCP uses a pseudo header based on IP3

But:

IPv6a EHb EHc TCP…TCP uses a pseudo header based on IPv6a; each of the EH’s can 
also refer back to IPv6a

I see NO way to do this with any mechanism for IPv4 except options (whose space 
is limited). There’s no way to redefine protocol processing to ensure that 
information can be “Carried” forward across EHs.

This seems like a show-stopper; has it been addressed?

Joe


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt

[Brian E Carpenter]

On 21-Mar-24 17:52, Tom Herbert wrote:

On Wed, Mar 20, 2024 at 9:35 PM Toerless Eckert  wrote:


On Wed, Mar 20, 2024 at 09:20:24PM -0700, Tom Herbert wrote:

In other words, Destination Option Headers do not have fundamentally distinct
processing requirements on the destination host examining it than any other
possible protocol header (e.g.: UDP, TCP), or at least we could not find such a 
description
for any such guiding rules or treatment differences in RFC8200.


Yes, that's mostly how all the IP protocols are implemented.
Processing of an encapsulated  protocol isn't completely independent,
for instance the pseudo header for the TCP and UDP checksum is
different for IPv4 and IPv6.


Right. But it seems unrelated to whether or not a header is an extension header,
TCP and UDP not being extension headers for example.


Of course, this interpretation is not fully consistent with the way the
"IPv6 Extension Header" flag is used in the registry: IPv6 itself does not have 
this
flag, so likely IPv4 should neither, even though both have this "next header" 
field,
but maybe this can be explained by both ofg these being recursion instead of 
extension
when happening in a header chain.


Yes, although it's not clear to me how relevant the flag in the
registry is. In any case, for IPv4 extension headers it makes sense to
be consistent with IPv6.


Well, i started this thread because i was worried thart there was some semantic
attached to the flag and changing it for existing protocols would cause 
potential
behavioral changes we would not want. But seemingly there is no actual semantic
implied, so we should be able to easily declare AH/ESP in IPv4 to be extension 
headers when
your draft goes through. the flag in the registry probably would only impact the
ability of packet parsers to parse at least the extension header chain.


Toerless,

Packet parsers would implement the protocol spec. If spec says there's
a Next Header then we'll parse it as a Next Header. I don't believe
the registry flags have any relevance to implementations.


Correct. The registry is set up to help humans identify extension
headers as such, and it has no significance on the wire.

   Brian
 


Tom



Cheers
 Toerless


Tom



Cheers
 Toerless

On Tue, Mar 05, 2024 at 05:56:54PM +0100, Toerless Eckert wrote:

On Mon, Mar 04, 2024 at 06:11:38PM -0800, Tom Herbert wrote:

We can treat them as EH for purposes of extension header ordering in
section 2.2. Also, IPv4 AH needs to be updated to take EH into account
as mentioned below. Other than that I don't believe there are any
substantive differences.


Yes, i am trying to use ESP/AH as examples to understand the benefits
of destination headers as opposed to just non-extension headers ..


No changes to APIs, we can use the same APis in IPv6 with IPv4. Kernel
changes to Linux will be straightforward.


My question was not about differences in API between IPv4/IPv6, but between when
ESP/AH are (as currently) NOT extension headers in IPv4 vs. after they become
extension because the kernel changes have been applied.

Ul;timately, i am trying to understand whether, and if so WHY we should
reclassify ESP and AH in IPv4 to be extension headers. Right now the only
argument i would know would be "consistency with IPv6", but that by itself
does not seem to be sufficient to change something for what's being deployed
worldwide in so many places. So there should be a technical benefit.

And if the answer is "it does not make any difference whatsoever", then i also
wonder why we would want to do it...


Any other functional differences ? Aka: i couldn't find a simple:

"If i want to define a new protocol header, should i call it an
  extension header or an ipv6 extension header - for Dummies" ?


I think there are IPv6 extension headers and IPv4 extension headers.
IPv4 extension headers are probably just a subset of IPv6 extension
headers.


That's certainly safer, e.g.: asking for a separate column in the IANA registry.


be renamed to "IP/IPv6 Extension Header". But when this was done
to AH/ESP, and there actually is a functional difference expressed by
this extension header (as opposed to non-extension header) status, then
what be the imapct of this ? Aka: I upgrade my linux kernel to extension
header and all my AH/ESP breaks ?  Or i do get the benefit of above
(userland access) ?

Would there be any (backward compatibility) reason to have new codepoints in 
IPv4 for ESP/AH
with this extension header status and leave the existing (non extension
header) codepoints alone ?


No, I don't think we need that. ESP/AH should be backwards compatible.
For instance, if someone sends AH with HBH in IPv4 then they know that
their using EH and AH would take into account mutable HBH options. If
the packet is sent to a host that supports IPv4 EH then they would
know how to process the AH with HBH correctly. If the packet is sent
to a legacy node that doesn't support EH, then the packet will bv
dropped since 

Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt

[Brian E Carpenter]

On 21-Mar-24 17:20, Tom Herbert wrote:

On Wed, Mar 20, 2024 at 8:36 PM Toerless Eckert  wrote:


Btw: When i asked on of the 6MAN chairs, about the meaning of an Internet 
Protocol
Number being an "IPv6 Extension Header" or not, the answer was that in his
interpretation it is simply whether the header itself has it's own "Next Header"
field using the IANA Assigned Internet Protocol Numbers registry - or not.


Thanks for asking. So by this definition IPv4 already supports
extension headers :-).


Well, look at 
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header
 and https://www.rfc-editor.org/rfc/rfc7045.html#section-4

We did try to clarify this.

   Brian





In other words, Destination Option Headers do not have fundamentally distinct
processing requirements on the destination host examining it than any other
possible protocol header (e.g.: UDP, TCP), or at least we could not find such a 
description
for any such guiding rules or treatment differences in RFC8200.


Yes, that's mostly how all the IP protocols are implemented.
Processing of an encapsulated  protocol isn't completely independent,
for instance the pseudo header for the TCP and UDP checksum is
different for IPv4 and IPv6.



To me this means that it's simply a matter of consistency of simply calling ESP 
and AH
"Extension Headers" when we do introduce this concept into IPv4.


Agreed.



Of course, this interpretation is not fully consistent with the way the
"IPv6 Extension Header" flag is used in the registry: IPv6 itself does not have 
this
flag, so likely IPv4 should neither, even though both have this "next header" 
field,
but maybe this can be explained by both ofg these being recursion instead of 
extension
when happening in a header chain.


Yes, although it's not clear to me how relevant the flag in the
registry is. In any case, for IPv4 extension headers it makes sense to
be consistent with IPv6.

Tom



Cheers
 Toerless

On Tue, Mar 05, 2024 at 05:56:54PM +0100, Toerless Eckert wrote:

On Mon, Mar 04, 2024 at 06:11:38PM -0800, Tom Herbert wrote:

We can treat them as EH for purposes of extension header ordering in
section 2.2. Also, IPv4 AH needs to be updated to take EH into account
as mentioned below. Other than that I don't believe there are any
substantive differences.


Yes, i am trying to use ESP/AH as examples to understand the benefits
of destination headers as opposed to just non-extension headers ..


No changes to APIs, we can use the same APis in IPv6 with IPv4. Kernel
changes to Linux will be straightforward.


My question was not about differences in API between IPv4/IPv6, but between when
ESP/AH are (as currently) NOT extension headers in IPv4 vs. after they become
extension because the kernel changes have been applied.

Ul;timately, i am trying to understand whether, and if so WHY we should
reclassify ESP and AH in IPv4 to be extension headers. Right now the only
argument i would know would be "consistency with IPv6", but that by itself
does not seem to be sufficient to change something for what's being deployed
worldwide in so many places. So there should be a technical benefit.

And if the answer is "it does not make any difference whatsoever", then i also
wonder why we would want to do it...


Any other functional differences ? Aka: i couldn't find a simple:

"If i want to define a new protocol header, should i call it an
  extension header or an ipv6 extension header - for Dummies" ?


I think there are IPv6 extension headers and IPv4 extension headers.
IPv4 extension headers are probably just a subset of IPv6 extension
headers.


That's certainly safer, e.g.: asking for a separate column in the IANA registry.


be renamed to "IP/IPv6 Extension Header". But when this was done
to AH/ESP, and there actually is a functional difference expressed by
this extension header (as opposed to non-extension header) status, then
what be the imapct of this ? Aka: I upgrade my linux kernel to extension
header and all my AH/ESP breaks ?  Or i do get the benefit of above
(userland access) ?

Would there be any (backward compatibility) reason to have new codepoints in 
IPv4 for ESP/AH
with this extension header status and leave the existing (non extension
header) codepoints alone ?


No, I don't think we need that. ESP/AH should be backwards compatible.
For instance, if someone sends AH with HBH in IPv4 then they know that
their using EH and AH would take into account mutable HBH options. If
the packet is sent to a host that supports IPv4 EH then they would
know how to process the AH with HBH correctly. If the packet is sent
to a legacy node that doesn't support EH, then the packet will bv
dropped since the host doesn't recognize protocol 0 (HBH).


Not clear. What you are writing implies that the encoding on the wire would
change for AH from what it is now. What's exactly the change ? It's not
in the next header field...


There is no
behavioral change at either the receiver or the 

Re: [Int-area] [spring] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

[Brian E Carpenter]

Tony,

On 02-Apr-23 05:53, Tony Przygienda wrote:

?

I heard the argument that IPv6 address space is large and "easy to carve up to mean 
other things" since about as long IPv6 started to gain traction. The wisdom of that 
has been thankfully so far questioned. BIER was also approached by people who hoped we 
would create a precedent by taking a /8 or /16 or something and use the rest of bits to 
stick bitmasks in. Expediency overriding architecture and all that usual jazz ...


I have all kinds of angst about using magic bit patterns in IPv6 addresses to 
convey semantics. Addresses are for getting packets from one end to other, 
period. However, my main interest is to prevent SRV6 SIDs doing any kind of 
damage to the universal deployment of IPv6. From that point of view, a new 
Ethertype would be great because it automatically prevents SRV6 SIDs deployment 
on the Internet rather than within limited domains.

But that doesn't affect what I said: *deploying* a new Ethertype is much, much 
harder than deploying draft-ietf-6man-sids.



Yes, it's easy to "quickly deploy" and taken to the bitter conclusion we'll stop having a decently 
economic, secure and debuggable IP forwarding path, instead we end up building IP host address firewall 
scanning things into layer 4 to find violations in complex constructs masquerading under addresses and IP 
"extension headers" and build lots of "kind of limited but not so limited and kind of 
secur'ish domains". Firewalls have their place but routers are not firewalls.


I don't see where layer 4 comes in. SRV6 adds semantics to layer 3. Layer 3 
ACLs have existed much longer than firewalls. draft-ietf-6man-sids enables the 
non-SRV6 Internet to drop SRV6 SIDs traffic without any kind of DPI, exactly as 
a new Ethertype would.

Regards
   Brian



-- tony

On Fri, Mar 31, 2023 at 9:00 PM Brian E Carpenter mailto:brian.e.carpen...@gmail.com>> wrote:

On 01-Apr-23 06:18, Ron Bonica wrote:
 > On second thought, if we had the new ethertype, we wouldn’t need the new 
/16!
 >
 > They serve the same function

However, a new special-purpose prefix is rather trivial to deploy compared 
with a new Ethertype.

     Brian

 >
 >      
Ron
 >
 > *From:* Ron Bonica
 > *Sent:* Friday, March 31, 2023 1:05 PM
 > *To:* Krzysztof Szarkowicz mailto:40juniper@dmarc.ietf.org>>; Kireeti Kompella mailto:kireeti.i...@gmail.com>>
 > *Cc:* Adrian Farrel mailto:adr...@olddog.co.uk>>; Andrew Alston - IETF 
mailto:40liquid.t...@dmarc.ietf.org>>; int-area@ietf.org 
<mailto:int-area@ietf.org>; spr...@ietf.org <mailto:spr...@ietf.org>; Dr. Tony Przygienda mailto:tonysi...@gmail.com>>
 > *Subject:* RE: [spring] [Int-area] FW: New Version Notification for 
draft-raviolli-intarea-trusted-domain-srv6-00.txt
 >
 > +1
 >
 > If we allocate a /16 for SRv6 USIDs, as proposed in 
https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt 
<https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt> 
<https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt 
<https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt>>,
 >
 > we can allow that prefix only when the new ethertype is used.
 >
 >  
  Ron
 >
 > *From:* spring mailto:spring-boun...@ietf.org> 
<mailto:spring-boun...@ietf.org <mailto:spring-boun...@ietf.org>>> *On Behalf Of *Krzysztof 
Szarkowicz
 > *Sent:* Wednesday, March 29, 2023 5:30 AM
 > *To:* Kireeti Kompella mailto:kireeti.i...@gmail.com> 
<mailto:kireeti.i...@gmail.com <mailto:kireeti.i...@gmail.com>>>
 > *Cc:* Adrian Farrel mailto:adr...@olddog.co.uk> <mailto:adr...@olddog.co.uk <mailto:adr...@olddog.co.uk>>>; Andrew Alston - IETF 
mailto:40liquid.t...@dmarc.ietf.org> <mailto:andrew-ietf <mailto:andrew-ietf>=40liquid.t...@dmarc.ietf.org 
<mailto:40liquid.t...@dmarc.ietf.org>>>; int-area@ietf.org <mailto:int-area@ietf.org> <mailto:int-area@ietf.org <mailto:int-area@ietf.org>>; spr...@ietf.org 
<mailto:spr...@ietf.org> <mailto:spr...@ietf.org <mailto:spr...@ietf.org>>; Dr. Tony Przygienda mailto:tonysi...@gmail.com> 
<mailto:tonysi...@gmail.com <mailto:tonysi...@gmail.com>>>
 > *Subject:* Re: [spring] [Int-area] FW: New Version Notification for 
draft-raviolli-intarea-trusted-domain-srv6-00.txt
 >
 > *[External Email. Be cautious of content]*
 >
 > SRv6 packet might have SRH, but might not have SRH. Especially with 
uSID, you can craft a decent SR-TE SRv6 packet without SRH. So I think, Kireet

Re: [Int-area] [spring] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

[Brian E Carpenter]

On 01-Apr-23 06:18, Ron Bonica wrote:

On second thought, if we had the new ethertype, we wouldn’t need the new /16!

They serve the same function


However, a new special-purpose prefix is rather trivial to deploy compared with 
a new Ethertype.

   Brian



     Ron

*From:* Ron Bonica
*Sent:* Friday, March 31, 2023 1:05 PM
*To:* Krzysztof Szarkowicz ; Kireeti 
Kompella 
*Cc:* Adrian Farrel ; Andrew Alston - IETF 
; int-area@ietf.org; spr...@ietf.org; Dr. Tony 
Przygienda 
*Subject:* RE: [spring] [Int-area] FW: New Version Notification for 
draft-raviolli-intarea-trusted-domain-srv6-00.txt

+1

If we allocate a /16 for SRv6 USIDs, as proposed in 
https://www.ietf.org/archive/id/draft-ietf-6man-sids-02.txt 
,

we can allow that prefix only when the new ethertype is used.

    
   Ron

*From:* spring mailto:spring-boun...@ietf.org>> *On 
Behalf Of *Krzysztof Szarkowicz
*Sent:* Wednesday, March 29, 2023 5:30 AM
*To:* Kireeti Kompella mailto:kireeti.i...@gmail.com>>
*Cc:* Adrian Farrel mailto:adr...@olddog.co.uk>>; Andrew Alston - IETF 
mailto:andrew-ietf=40liquid.t...@dmarc.ietf.org>>; int-area@ietf.org 
; spr...@ietf.org ; Dr. Tony Przygienda mailto:tonysi...@gmail.com>>
*Subject:* Re: [spring] [Int-area] FW: New Version Notification for 
draft-raviolli-intarea-trusted-domain-srv6-00.txt

*[External Email. Be cautious of content]*

SRv6 packet might have SRH, but might not have SRH. Especially with uSID, you 
can craft a decent SR-TE SRv6 packet without SRH. So I think, Kireetis’ 
comments should apply to all SRv6 packets (with/without SRH).

—

Krzysztof

On 2023 -Mar-29, at 17:57, Tony Przygienda mailto:tonysi...@gmail.com>> wrote:

Though I would like to cheer for Kireeti's 2. as well I think the point of 
SHOULD is more realistic (for now) as Joel points out ...

As to ethertype, I think grown-ups in the room were since long time drily 
observing that a new IP version would have been appropriate after enough 
contortions-of-it's-an-IPv6-address-sometimes-and-sometimes-not-and-sometimes-only-1/4
 were performed with drafts whose authors' list length sometimes rivaled pages 
of content ;-)  I think this ship has sailed and that's why after some 
discussions with Andrew we went the ether type route as more realistic. 
Additionally, yes, lots encaps (not encodings) carrying SRv6 should get new 
codepoints if we are really serious about trusted domains here.

And folks who went the MPLS curve know that none of this is new, same curve was walked roughly 
(though smoother, no'one was tempted to "hide label stack in extension headers" ;-) and 
it would go a long way if deploying secure SRv6 becomes as simple as *not* switching on 
"address family srv6" on an interface until needed and then relying on BGP-LU (oops ;-) 
to build according lookup FIBs for SRv6 instead of going in direction of routers becoming massive 
wildcard matching and routing header processing firewalls ...

--- tony

On Wed, Mar 29, 2023 at 4:33 PM Kireeti Kompella mailto:kireeti.i...@gmail.com>> wrote:

On Mar 28, 2023, at 11:24, Adrian Farrel mailto:adr...@olddog.co.uk>> wrote:

[Spring cc’ed because, well, you know, SR. I wonder whether 6man 
and 6ops should care as well.]

SPRING cc’ed because, you know, replying to Adrian’s email.  Agree that 
6man and 6ops [sh|w]ould be interested.

tl;dr

I think this is a good initiative and worth discussion. Thanks

for the draft.

Agree.  In particular:

1. There is an acknowledged security problem. Might be worth 
summarizing, as it is central to this draft, but an example is in rfc 
8402/section 8. Section 3 of this draft (“The SRv6 Security Problem”) doesn’t 
actually describe the security problem; Section 5 does, briefly.

2. The solution (using a new EtherType, SRv6-ET) is a good one.  It’s 
sad that this wasn’t done from the get-go, as the solution is a bit “evil 
bit”-ish.  I’d prefer to see ALL SRv6 packets (i.e., those containing SRH) use 
SRv6-ET.  Boundary routers SHOULD drop packets with SRv6-ET that cross the 
boundary in either direction; all routers MUST drop packets with SRH that don’t 
have SRv6-ET. Yeah, difficult, but the added security is worth it.

3. Ease of secure deployment is a major consideration; this draft is a 
big step in that direction.

4. As Adrian said, several nits.  Will send separately to authors.

Kireeti

___
spring mailing list
spr...@ietf.org 
https://www.ietf.org/mailman/listinfo/spring 

Re: [Int-area] [spring] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

[Brian E Carpenter]

On 30-Mar-23 21:00, Tony Przygienda wrote:

+1 Joel

AFAIS it's same effort to upgrade something to process SRH or to process new ethertype 
properly. And in a sense upgrade to something that drops ether type SRv6 if it's not 
supposed to be processed is no upgrade today, routers as per today will pretty much do it 
automatically creating a TD boundary for free. That's the jest of the draft.  And as Joel 
pointed out sending SRv6 through open internet v6 routers is peeling stickers off the 
standards anyway so strictly speaking per standard anything that shows up from the 
"wide, wild, free Internet" that looks like IPv6 but tries to be SRv6 is pretty 
much an attack ;-)

Inside the trusted domain one could not use the ether type but forward on pseudo-IPv6-address since 
we're in the "limited domain" (as Muthu ponders) but then anything that can send out a v6 
packet to any destination (as e.g. completely benign, non-raw user space socket) can start SRv6 
attacks (at least without SRH) as we know and the burden of "how do we stop it from leaving 
the TD without ether type" gets us back into the whole 'router-srh-processing-firewall' 
discussion ...


Well yes. We tried to make this a bit more concrete in 
https://www.rfc-editor.org/rfc/rfc8799.html#name-functional-requirements-of-

Relying on human-based configuration seems prone to errors and loopholes.

   Brian



-- tony

On Thu, Mar 30, 2023 at 1:29 PM Joel Halpern mailto:j...@joelhalpern.com>> wrote:

Not quite, but close.

Routers which are not upgraded, and receive packets with the new ethertype, 
will drop them.  Which theoretically is fine for routers which are not intended 
to be on SRv6 paths.  Practically, since you want to be able to run the paths 
where you need them, you probably do need to upgrade all routers to accept and 
propagate the new ethertype if you want to use this solution.  For some 
operators, that is a show stopper and they will not use this capabilities.  For 
others, it is quite deployable, and even helpful in keeping control of what 
servicces are offered where.

Yours,

Joel

On 3/29/2023 12:00 PM, Muthu Arul Mozhi Perumal wrote:

So, using the new ethertype inside a (closed/open) domain would require all 
IPv6 routers inside the domain to support SRv6 or at least support the new 
ethertype to check if any IPv6 packet containing an SRH was received with this 
ethertype? If an IPv6 router supports neither, then one cannot enable this 
feature on any of its neighbor's interface, right?

Regards,
Muthu

On Wed, Mar 29, 2023 at 5:40 PM Robert Raszuk mailto:rob...@raszuk.net>> wrote:

Nope, that is completely not what I have in mind,

Please remember that transit nodes are not SRv6 aware in closed or open 
domain, So my site A (car) can be using SRv6 via any IPv6 transit uplink to my 
MEC or private DC where services are being properly demuxed based on the 
SID/uSID.

If you close this date plane option by new ethertype my car is 
disconnected,

So I am not sure who is  "incredibly naive" here or perhaps to put it a 
bit more politely who does not understand the power of new technology.

Regards,
R.


On Wed, Mar 29, 2023 at 5:02 AM Mark Smith mailto:markzzzsm...@gmail.com>> wrote:

On Wed, 29 Mar 2023 at 22:46, Robert Raszuk mailto:rob...@raszuk.net>> wrote:
>
> Guys,
>
> What you are really saying here is that the concept of using 
network programmability should be killed and we should get stuck for decades to 
come with closed domains only innovation.
>
> I find it quite disturbing especially as we are talking about 
Internet Engineering Task Force produced standards here.
>
> Yes it has been derailed {not to say hijacked} into 
standardization of private extensions for various protocols which are limited to 
closed domains as the technology of new forwarding paradigm called MPLS simply by 
design was not applicable to be deployed in the open Internet. But that should not 
mean we should get stuck with this till new generation understands mistakes made 
and moves forward,
>
> It is obvious that those who invested heavily in MPLS will fight 
to protect it no matter what. But new technologies and services are being deployed 
over SRv6 using native IPv6 dataplane. Examples are mobile nodes which move from 
network to network.
>
> Is this closed domain - no by any means. Is it working today - 
yes pretty well.
>
> So proposing a new ethertype for SRv6 today seems to be 
comparable to putting a stick into the wheels of a cool bicycle starting to gain 
speed.
>

If you believe one network operator is going to let another network
operator program the first network operator's network, then I think
you're incredibly 

Re: [Int-area] [spring] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

[Brian E Carpenter]

Robert,

On 30-Mar-23 01:10, Robert Raszuk wrote:

Nope, that is completely not what I have in mind,

Please remember that transit nodes are not SRv6 aware in closed or open domain, So my site A (car) can be using SRv6 via any IPv6 transit uplink 


Only if the SRv6-carrying IPv6 packet is encapsulated inside a normal IPv6 packet. 
Otherwise, as we know from RFC 7872 and ongoing work, the Internet is not transparent to 
IPv6 packets carrying "unknown" extension headers.

Since that situation has been blocked for many years (and the equivalent 
operational situation for unknown IPv4 options has been blocked for many more 
years), I think the fact that SRv6 semantics are local within a trust boundary 
is unlikely to change.

(As for deploying a new Ethertype on every switch and router in the world, 
well, good luck with that, since it will be as hard as deploying IPv6, which we 
have still only achieved to 42.95% according to Google's graph for March 25.)

Regards
   Brian


to my MEC or private DC where services are being properly demuxed based on the 
SID/uSID.

If you close this date plane option by new ethertype my car is disconnected,

So I am not sure who is  "incredibly naive" here or perhaps to put it a bit 
more politely who does not understand the power of new technology.

Regards,
R.


On Wed, Mar 29, 2023 at 5:02 AM Mark Smith mailto:markzzzsm...@gmail.com>> wrote:

On Wed, 29 Mar 2023 at 22:46, Robert Raszuk mailto:rob...@raszuk.net>> wrote:
 >
 > Guys,
 >
 > What you are really saying here is that the concept of using network 
programmability should be killed and we should get stuck for decades to come with 
closed domains only innovation.
 >
 > I find it quite disturbing especially as we are talking about Internet 
Engineering Task Force produced standards here.
 >
 > Yes it has been derailed {not to say hijacked} into standardization of 
private extensions for various protocols which are limited to closed domains as 
the technology of new forwarding paradigm called MPLS simply by design was not 
applicable to be deployed in the open Internet. But that should not mean we should 
get stuck with this till new generation understands mistakes made and moves 
forward,
 >
 > It is obvious that those who invested heavily in MPLS will fight to 
protect it no matter what. But new technologies and services are being deployed 
over SRv6 using native IPv6 dataplane. Examples are mobile nodes which move from 
network to network.
 >
 > Is this closed domain - no by any means. Is it working today - yes 
pretty well.
 >
 > So proposing a new ethertype for SRv6 today seems to be comparable to 
putting a stick into the wheels of a cool bicycle starting to gain speed.
 >

If you believe one network operator is going to let another network
operator program the first network operator's network, then I think
you're incredibly naive about how the multi-party Internet is operated
and the security and availability concerns network operators have.



 > Respectfully to all td-srv6 authors and cheerleaders,
 > Robert
 >
 >
 > On Wed, Mar 29, 2023 at 1:58 AM Tony Przygienda mailto:tonysi...@gmail.com>> wrote:
 >>
 >> Though I would like to cheer for Kireeti's 2. as well I think the point 
of SHOULD is more realistic (for now) as Joel points out ...
 >>
 >> As to ethertype, I think grown-ups in the room were since long time 
drily observing that a new IP version would have been appropriate after enough 
contortions-of-it's-an-IPv6-address-sometimes-and-sometimes-not-and-sometimes-only-1/4
 were performed with drafts whose authors' list length sometimes rivaled pages of 
content ;-)  I think this ship has sailed and that's why after some discussions with 
Andrew we went the ether type route as more realistic. Additionally, yes, lots encaps 
(not encodings) carrying SRv6 should get new codepoints if we are really serious 
about trusted domains here.
 >>
 >> And folks who went the MPLS curve know that none of this is new, same curve was walked 
roughly (though smoother, no'one was tempted to "hide label stack in extension headers" ;-) and 
it would go a long way if deploying secure SRv6 becomes as simple as *not* switching on "address 
family srv6" on an interface until needed and then relying on BGP-LU (oops ;-) to build according 
lookup FIBs for SRv6 instead of going in direction of routers becoming massive wildcard matching and 
routing header processing firewalls ...
 >>
 >> --- tony
 >>
 >>
 >>
 >> On Wed, Mar 29, 2023 at 4:33 PM Kireeti Kompella mailto:kireeti.i...@gmail.com>> wrote:
 >>>
 >>> On Mar 28, 2023, at 11:24, Adrian Farrel mailto:adr...@olddog.co.uk>> wrote:
 >>>
 >>> [Spring cc’ed because, well, you know, SR. I wonder whether 6man and 
6ops should care as well.]
 >>>
 >>>
 >>> SPRING cc’ed because, you know, replying to Adrian’s 

Re: [Int-area] Jumbograms [was: Call for WG adoption of draft-templin-intarea-parcels-10]

[Brian E Carpenter]

Gyan,

https://mailarchive.ietf.org/arch/msg/int-area/gNA1peWM46q1upmSybUkcd9MUtY

There was also this report sometime last year (look for slide 8):

https://netdevconf.info/0x15/session.html?BIG-TCP

Regards
   Brian Carpenter

On 04-Jul-22 00:42, Gyan Mishra wrote:


Thanks Brian for 6MAN clarification on RFC 2365 that it has been implemented 
for very specialized environments.

I agree it does no harm to anyone who doesn’t use it.

What is the application where it was implemented if you have a link would be 
greatly appreciated.

Thanks

Gyan

On Sun, Jul 3, 2022 at 1:08 AM Brian E Carpenter mailto:brian.e.carpen...@gmail.com>> wrote:

Hi Gyan,

On 03-Jul-22 16:25, Gyan Mishra wrote:
...
 > So bottom line is RFC 2675 would never come to fruition and should 
really be deprecated or made obsolete.

Why? Firstly, it has come to fruition, as an earlier message in this thread 
said. Secondly, it was intentionally designed for very special environments 
with unusual hardware, rather than for any commodity environment. Thirdly, it 
does no harm whatever to anyone that doesn't use it, so there is no reason 
whatever to deprecate it.

 > I believe this was discussed on 6MAN.

I believe the conclusion was to leave it as is.

     Brian

--

<http://www.verizon.com/>

*Gyan Mishra*

/Network Solutions A//rchitect /

/Email gyan.s.mis...@verizon.com <mailto:gyan.s.mis...@verizon.com>//
/

/M 301 502-1347

/



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] Jumbograms [was: Call for WG adoption of draft-templin-intarea-parcels-10]

[Brian E Carpenter]

Hi Gyan,

On 03-Jul-22 16:25, Gyan Mishra wrote:
...

So bottom line is RFC 2675 would never come to fruition and should really be 
deprecated or made obsolete.


Why? Firstly, it has come to fruition, as an earlier message in this thread 
said. Secondly, it was intentionally designed for very special environments 
with unusual hardware, rather than for any commodity environment. Thirdly, it 
does no harm whatever to anyone that doesn't use it, so there is no reason 
whatever to deprecate it.


I believe this was discussed on 6MAN.


I believe the conclusion was to leave it as is.

   Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [Iotops] Last Call: Moving TPC.INT and NSAP.INT infrastructure domains to historic

[Brian E Carpenter]

Toerless,

I've seen no evidence that nsap.int is used by anyone anywhere for anything.

If there was any use for it, I'm sure it would have been migrated to nsap.arpa
a long time ago.

Regards
   Brian

On 07-Apr-22 21:38, Toerless Eckert wrote:

[ Disclaimer: Cc some more mailing list in the hope that it would help to reach
more technical and administrative contributors to the specific aspects asked for
IETF than those who can afford to track an IETF wide list such as last-call.]

0. Confused

I am really confused about the email, because the subject refers to making 
domain
infrastructures historic, whereas the text asks for making RFCs historic. I am
commenting on the ask to make RFCs historic.

1.  RFC1706 from Informational to Historic (DNS NSAP Resource Records)

Back in the 80th/90th when i was working on CLNP (and IAB until after Kobe too 
? ;-)),
i already found it quite difficult back then to figure out how much CLNP was 
actually used,
and seemingly most use was in closed industrial environments, although those
deployments sometimes even just used TP4 over Ethernet, but (AFAIR) still with
NSAPs. My ability to vet if or how much CLNP or in a broader sense NSAP are
in active use in any closed networks has not become better. Even less so any
possible use of RFC1706. So, what to do in the absence of knowledge but often
reconfirmed fear of unknown usage... ?

1.a)
Given how CLNP/X.233 is to the best of my understanding an active/enforced
standard at ISO/OSI and ITU-T, it would certainly be useful to consider bringing
the suggested change to the attention of those SDO through our liaison 
mechanism.
Any positive feedback from their side would be extremely helpful.

Short of getting real insight into how relevant/irrelevant NSAP really are today
in badly visible environment, i think we do not win anything by changing status
from informational to historic. Instead, we are assuming that we know something.
Which i think we don't. In which case we should just keep it as is.

1.b)

Personally i am saying that i wish for RFC1706 not be moved to historic,
because to me historic not only means not--used, but also technically-obsolete,
and given how NSAP are variable length, IPv6 is not, and many proposals in the 
IETF
have argued for variable length addressing at the network layer to better solve
problems, my opinion is that we should move something like this only to historic
when we have something equal or better. E.g.: after we have updated IPv6 to
also support variable length addresses.

2.) RFC1528 from Experimental to Historic

I am not aware of a better, interoperable standard solution for remote printing 
(or should
i say Internet FAX ?). Instead it feels to me as if every printer vendor has 
started
its own proprietary remote-printing cloud-service. I hope i am wrong (pointers 
please),
but if not, then i fear this decade old experiment is still the best we have ?

See 1.b) about arguing to changing status for something where there is no new
evidence of there being something better and/or the mechanism being technically
flawed (as opposed to just not being enough in the interest of vendors 
attempting
to create monopolistic silos...)

Cheers
 Toerless

On Wed, Mar 30, 2022 at 02:18:07PM -0700, The IESG wrote:

-
Please note: This is a second IETF LC.

This isn't really a document (or at least a document that does anything).
The "IESG Statement on Designating RFCs as Historic" 
(https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/ 
) says that:
"The current process, then, of moving an RFC to Historic status is to follow 
one of these, depending upon the level of documentation and discussion of the 
documentation required:
1: [...]
2: "An individual or a working group posts an Internet Draft containing an 
explanation of the reason for the status change. The I-D is discussed and iterated as 
usual for I-Ds. At some point, it is sent to an appropriate AD to request publication. 
The AD creates a status-change document, with an explanation that points to the I-D. The 
I-D and the status-change are then last-called together, after which the IESG evaluates 
and ballots on both." [...]
3: "As #2 above, except that the I-D might also contain other information. In this 
case, after IESG approval the I-D is sent to the RFC Editor. When the RFC is published, 
the status-change document is changed to point to the RFC instead of the I-D." [...]

This last call is *just* for the status change document 
(https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic), which is 
just a supporting document for 
https://datatracker.ietf.org/doc/draft-davies-int-historic/ (which does the 
actual work and explains stuff).
Basically, this is process-wonkey - please read 
https://datatracker.ietf.org/doc/draft-davies-int-historic/ instead, it's much 
more useful an interesting...




The IESG has received a request from an individual participant to make the
following 

Re: [Int-area] New draft: The IETF Will Continue Maintaining IPv4 (draft-schoen-intarea-ietf-maintaining-ipv4)

[Brian E Carpenter]

Hi,


Please let us know if you have any questions after reading the
draft.


I have no questions.

IMHO the draft is unnecessary and potentially harmful. It's a
matter of common sense that the IETF will fix things that *need*
fixing, even if they are specific to IPv4. It's a matter of fact
that IPv4 will continue to coexist with IPv6 until nobody uses
IPv4 any more. But it would be a mistake to apply scarce IETF
resources for anything but serious fixes, and this draft opens
the door to that. Consider for example the phrase "ongoing
standardization" near the end of section 7. That is exactly
what we do not need.

FWIW I do not consider the minor wastage of IPv4 addresses that
the same authors are concerned about to be serious enough to need
fixing. We shouldn't be fixing problems that IPv6 already fixes,
and shortage of addresses is certainly in that category.

When there is an issue that is serious enough to justify IETF
effort, and specific to IPv4, the intarea WG charter already
allows for it. That's why this draft seems unnecessary to me.

Regards
   Brian Carpenter

On 16-Mar-22 07:59, Seth David Schoen wrote:

Hi intarea,

When we presented our reserved address space drafts at the previous IETF
meeting, we noticed that the most common concern was not so much about
the substance of our proposals as about the question of whether intarea
and the IETF should be working on IPv4 fixes at all.

This question has been discussed on and off over the past few years. It
was, in a way, the subject of an entire now-concluded working group in
its own right (sunset4).  We thought we should go to the heart of the
matter and propose to confirm that the IETF intends to keep maintaining
IPv4.

As our draft notes, this is the opposite of a proposed consensus item
from sunset4 which stated that the IETF would stop working on IPv4.  That
notion raised many concerns for community members, and we now hope to
see whether a consensus to continue maintaining IPv4 can be found.

Our draft emphasizes that IPv4 is the most-used network layer protocol
in the world, that it's expected to be widely used for the foreseeable
future, that the IETF is the historic home of IPv4 standardization, and that
there continue to be coordination tasks for IPv4 implementations which
the IETF is best-suited to host.  Those include not only our own proposals
about address space, but also numerous work items on various IPv4 topics
that have arisen and become RFCs over the past decade.

Our draft does not question or alter the community's consensus in favor
of IPv6 adoption, but states that neglecting IPv4 is not a part of the
IETF's transition plan.

You can find it at

https://datatracker.ietf.org/doc/draft-schoen-intarea-ietf-maintaining-ipv4/

We invite discussion leading up to our presentation and Q at the
intarea session (13:30 UTC) on Tuesday, March 22, during IETF113 in
Vienna.  Please let us know if you have any questions after reading the
draft.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

[Brian E Carpenter]

Toerless,

I believe the closest we ever got to agreed definitions was in the
IRTF RFC 6115:

   6.   A "locator" is a structured topology-dependent name that is not
used for node identification and is not a path.  Two related
meanings are current, depending on the class of things being
named:

1.  The topology-dependent name of a node's interface.

2.  The topology-dependent name of a single subnetwork OR
topology-dependent name of a group of related subnetworks
that share a single aggregate.  An IP routing prefix is a
current example of the latter.

   7.   An "identifier" is a topology-independent name for a logical
node.  Depending upon instantiation, a "logical node" might be a
single physical device, a cluster of devices acting as a single
node, or a single virtual partition of a single physical device.
An OSI End System Identifier (ESID) is an example of an
identifier.  A Fully Qualified Domain Name (FQDN) that precisely
names one logical node is another example.  (Note well that not
all FQDNs meet this definition.)

Regards
   Brian

On 05-Mar-22 00:39, Toerless Eckert wrote:

On Thu, Mar 03, 2022 at 09:28:23AM -0800, Dino Farinacci wrote:

of its address structure helps the underlay to locate the entity (xTR) that the
address is assigned to (xTR). So the name 'locator' is 'just' a good
name for what LISP calls/uses the address for, not for how the under
itself would maybe call the address or use the address for.


Well the locator you put in an outer header destination address is 
called/used/assign to whatever the rules of the underlay are. If the underlay 
is ethernet, then its a 6-byte address where the high-order 3 bytes is an 
organizational ID, just to cite an example.


Indeed.

I have not seen an answer to the question i posed earlier in the thread:
  whether and if so what general (not technology specific) definition of locator
and identifier the IETF may have. But i have seen a lot of confusion about
it and people shying away from using these terms.

If (as i think) we do not have a commonly applicable definition of 
locator/identifier
(beyond its use in indivdual technologies like LISP), then i think this is 
because
folks who tried to apply these terms (incorrectly) may have failed to
see the difference between what an address is and what someone (like an
application) calls it (/uses it for). In that respect the reference to
the White Knight in IEN19 is very helpful to remember.

Cheers
 Toerless


Dino




___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

[Brian E Carpenter]

On 26-Jan-22 08:30, Geoff Huston wrote:
...

Tom,

I think you may have missed my initial characterisation of IP addresses 
in your response: "we treat addresses as no more than temporary ephemeral 
_session_ tokens” i.e. the NAT model relies on session level stability of the NAT association.


Right. And it's well understood that users don't care about addresses (unless 
circumstances force them to, such as instructions to browse to 10.1.1.1 to set 
up their new home gateway). I don't think much has changed since my rant 8 
years ago (https://dl.acm.org/doi/10.1145/2602204.2602215).

It increasingly seems to me that what we lack is some kind of transaction 
identifier that can survive both changes of address and transport layer failures. Possibly this is what OSI called the session layer.
 

My comment about QUIC is that the QUIC protocol does not even require that 
session-level stability of address association, and QUIC sessions essentially 
require stability of association only on a time basis approaching the RTT 
interval.

If you wish to construe various judgemental observations (Like "NAT is evil”, 
“NBATs break stuff”, etc,) feel free, but they are your constructions, not mine. The 
issue for me is not judgments of “good” or “bad”, but simply to explore, without 
overtones of judgement, exactly what an IP address represents in today’s Internet.


I just reread RFC2101. I wouldn't change a word, especially this:

"Thus, IPv6 will amplify the existing
problem of finding stable identifiers to be used for end-to-end
security and for session bindings such as TCP state.

The IAB feels that this is unfortunate, and that the transition to
IPv6 would be an ideal occasion to provide upper layer end-to-end
protocols with temporally unique identifiers. The exact nature of
these identifiers requires further study."

Here we are.

Regards
Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[Brian E Carpenter]

On 20-Dec-21 22:35, Dirk Trossen wrote:

Jumping into this late (due to a few days off), see inline.

-Original Message-
From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Brian E Carpenter
Sent: 18 December 2021 20:51
To: Stewart Bryant ; Geoff Huston 
Cc: Int-area@ietf.org
Subject: Re: [Int-area] Where/How is the features innovation happening?

On 18-Dec-21 23:00, Stewart Bryant wrote:
...

What is important is that we play the cards we are dealt not the ones we were 
dealt in the last game. In other words we need to design for the Internet as it 
will be, not the Internet we designed before and not the Internet that we would 
wish for but which is not economically viable.



I don't think that helps. We don't have an accurate crystal ball, any more than 
our predecessors did in the late 1970s. They designed a network that was 
peer-to-peer at the network layer *and* that was cheaper to implement and 
operate than various alternatives (such as X.25, ISDN, and ATM). Capitalism 
took that and ran with it, producing an Internet with increasingly concentrated 
services at the application layer but still peer-to-peer at the packet level; 
it's just that application services are peer-to-service-to-peer. I have no idea 
whether anybody predicted that in the 1970s, but most people didn't.



[DOT] We may not have a crystal ball, indeed, but there are aspects that 
outline a desired path forward, termed 'principles'. To what end those 
principles will be used may be a different matter but they do provide a stake 
in the ground when moving ahead from them.

Unless crystal ball technology has improved since the 1970s, I don't see how we will 
predict "the Internet as it will be".



[DOT] So if we conclude (somehow) the discussions in previous contributions, the P2P 
nature of communication between hosts seemed to have been a crucial principle that was 
considered in the addressing (and routing) work?! Whether it is host->host or 
host->service->host (as we may see predominantly in today's communication) is 
somewhat irrelevant from that principle's perspective, is it not?

[DOT] If we now observe an increase in host->service->host communication, we may 
wonder how to possibly better support this pattern, not just in the light of the 
economically driven centralization of that model but also keeping the more P2P-driven 
principle alive in realizing host->service->host communication? There is work 
providing answers to this question albeit more aligned with the predominant centralized 
service provisioning model (see https://dl.acm.org/doi/pdf/10.1145/3452296.3472922 for one 
such answer).

[DOT] Key question here may be what 'service' is of importance, particularly to 
the end user? The draft below provides some answers BUT...

If we think that services will continue to predominate, we could focus on that, 
but it might be a completely wrong guess.
https://datatracker.ietf.org/doc/draft-jiang-service-oriented-ip/
https://doi.org/10.1109/INFOCOMWKSHPS50562.2020.9162749

[DOT] from reading through the draft, the realization of the SAT seem (to me) 
to imply a rather significant semantic knowledge at the 'SOIP dispatcher' role 
- or am I missing something?



No, that's correct, and the idea would need a lot more work to turn it into reality. It 
could be that the dispatcher would really be a policy engine ("User wants search, 
policy => DuckDuckGo"). The main point is: what happens if we no longer think of the 
destination address being the primary invariant for routing a packet?

Also referencing back to my question on what 'service' constitutes, the draft seems to span from 'network service' to higher layer services, which links back into the 'dispatcher complexity' question before. Can we have something simpler? 



When you look at the raw HTML of a typical web page today, you quickly realise 
where the real complexity is today. So I think the real question is where to 
set the boundary between reasonably simple (like an IP address) and too complex 
for line speed processing. It's clearly a moving boundary, e.g. RFC8986.


Also, can there be a stronger combination of (existing) IPv6 routing and 
service routing (also for efficiency purposes), e.g., for supporting affinity 
of longer-running transactions?



I don't know. Carrying a transaction identifier at layer 3 sounds like an 
attractive idea, but our experience with the IPv6 flow label isn't encouraging.

   Brian
 


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[Brian E Carpenter]

On 19-Dec-21 11:34, Dino Farinacci wrote:

 From a user perspective, the choice is clear: privacy and security are
top requirements. We know that payload encryption goes a long way, and
hopefully encryption of the transport layer headers will become
dominant so that intermediate nodes will stop meddling and ossifying
the transport layer. But not everything can be encrypted, the IP
addresses for instance, so providing real security and privacy at the
plaintext network layer should be on the list of features to support
user requirements.


Definitely agree Tom.

But what if we sent a packet where the source address was encrypted? Then you 
could have global unique addresses (if you wanted them). Of course key exchange 
and rekeying parameters would have to be setup prior to sending a single packet.


It's called SNA (Sourceless Network Architecture):
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-849.pdf

   Brian


Maybe its just simpler to randomize addresses.

Dino



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[Brian E Carpenter]

On 18-Dec-21 23:00, Stewart Bryant wrote:
...  

What is important is that we play the cards we are dealt not the ones we were 
dealt in the last game. In other words we need to design for the Internet as it 
will be, not the Internet we designed before and not the Internet that we would 
wish for but which is not economically viable.



I don't think that helps. We don't have an accurate crystal ball, any more than 
our predecessors did in the late 1970s. They designed a network that was 
peer-to-peer at the network layer *and* that was cheaper to implement and 
operate than various alternatives (such as X.25, ISDN, and ATM). Capitalism 
took that and ran with it, producing an Internet with increasingly concentrated 
services at the application layer but still peer-to-peer at the packet level; 
it's just that application services are peer-to-service-to-peer. I have no idea 
whether anybody predicted that in the 1970s, but most people didn't.

Unless crystal ball technology has improved since the 1970s, I don't see how we will 
predict "the Internet as it will be".

If we think that services will continue to predominate, we could focus on that, 
but it might be a completely wrong guess.
https://datatracker.ietf.org/doc/draft-jiang-service-oriented-ip/
https://doi.org/10.1109/INFOCOMWKSHPS50562.2020.9162749

Regards
 Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[Brian E Carpenter]

On 18-Dec-21 10:58, Tom Herbert wrote:

On Fri, Dec 17, 2021 at 12:07 PM to...@strayalpha.com
 wrote:


Globally unique != static.

They can be randomized and varied over time, e.g., as are Ethernet MAC 

addresses, exactly for the reasons you note.


I would agree with that if the time to randomize is basically so small
that a client can use a unique and un-correlatable address for each
connection. Given the data collection abilities and compute resources
available to those that want to engage in surveillance, any time for
randomizing addresses, be it a day, an hour, or a few minutes, that is
greater than this minimum only provides a false sense of security with
respect to trying to prevent third parties from making correlations
about the sender's identity between different flows on the Internet.
Interestingly, CGNAT with enough users behind it can provide these
properties (attested by the fact the law enforcement has complained
about it).


If we care about the peer-to-peer property, varying addresses require a rendezvous process based on a non-varying identifier. It's then the latter 
that becomes the handle for surveillance and forensics. The real impact of CGNAT is to push that factoid into surveillance models; it gives IPv4 the same privacy assist that temporary addresses give IPv6.


So perhaps what we need is a surveillance-proof rendezvous mechanism.

   Brian



Tom



Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

On Dec 17, 2021, at 11:46 AM, Brian E Carpenter  
wrote:

On 18-Dec-21 07:48, Geoff Huston wrote:
...

So, to repurpose some graffiti from the 1970’s, we need globally unique 
addresses like fish need bicycles! :-)


They have residual value for surveillance and possibly other forensic uses, 
which may of course be actively harmful to the user.

But on the other hand, while what you say about economics is undoubtedly true, don't we want to keep the peer-to-peer option open *as a matter of principle*? After all, we still have that option for phone calls, even 

though it's now a minority usage pattern for mobile devices.


Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Where/How is the features innovation happening?

[Brian E Carpenter]

On 18-Dec-21 07:48, Geoff Huston wrote:
...

So, to repurpose some graffiti from the 1970’s, we need globally unique 
addresses like fish need bicycles! :-)


They have residual value for surveillance and possibly other forensic uses, 
which may of course be actively harmful to the user.

But on the other hand, while what you say about economics is undoubtedly true, 
don't we want to keep the peer-to-peer option open *as a matter of principle*? 
After all, we still have that option for phone calls, even though it's now a 
minority usage pattern for mobile devices.

Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

[Brian E Carpenter]

On 08-Dec-21 05:30, to...@strayalpha.com wrote:
...

But you make another point which is pretty fundamental and foundational. Should 
data links be MTU-less, so to speak? And can they really do that. I won't hold 
my breath.


I don’t know yet, but I do know that’s what I *want* and why it’s different 
than simply assuming a smaller MTU anywhere in the system.


I think you'll need to discuss this point with the inventors of packet 
switching and queueing theory. Since the Internet is still basically a great 
big statistical multiplexer, getting rid of MTU at every layer seems like an 
impossibility.

   Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

[Brian E Carpenter]

On 07-Dec-21 12:06, Tom Herbert wrote:

On Mon, Dec 6, 2021 at 1:52 PM Dino Farinacci  wrote:


Last email was the main point I wants to get across. Now to answer your 
questions inline.


On Dec 6, 2021, at 4:28 AM, Luigi Iannone  wrote:

Having said that, this is not caused by addressing itself, right?


Right, IMHO.


Certainly  large addresses eat a lot of that MTU space.


Well true as well as overlay encapsulation.

I wonder if we are able to describe this as a possible way to add features. Assuming we are able somehow to get rid of the MTU issue, it seems 

we gain a degree off freedom, how this translates specifically for the 
addressing?


I think the question is Luigi is, does the user notice an improvement in 
network performance by sending larger packets?


Dino,

Definitely at least for a limited domain. For instance, AFAIK Google
is using 9K MTUs in their internal networks. Whether the benefits of a
larger MTU scales to the whole Internet is probably still an open
question, however QUIC seems to require at least an MTU of 1280 bytes
so there are some attempts to enforce a baseline MTU for the Internet
greater than the specified minimums (at least greater than 64 bytes or
576 bytes for IPv4 MTU minimums.


Google is allegedly using more than 9000 for performance reasons.
Potentially, much more:
https://netdevconf.info/0x15/session.html?BIG-TCP

RFC2675 rocks.

   Brian



Tom



If so then the MTU issues we see as geeks at the network layer should be fixed. 
But note it’s hard (read: really hard if not impossible) to upgrade the 
underlay.

Dino
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Expanding Assignable IPv4 Public Address Re: 202112030945.AYC

[Brian E Carpenter]

Abe mentions "more efficient and productive use of our resources" and I think 
we all wish for that.

I think this WG should discuss the general question whether the minor wastage 
of IPv4 address space that this set of drafts addresses is an efficient and 
productive use of our resources. In other words, where are we with respect to 
conditions (1) - (5) in the WG charter 
(https://datatracker.ietf.org/wg/intarea/about/)?

Incidentally, the WG milestones look a bit OBE.

Regards
   Brian

On 04-Dec-21 12:09, Abraham Y. Chen wrote:

Dear Colleagues:

0)    I was just made aware of a current IETF Draft discussion on reducing the 127/8 netblock allocated for Local Loopback to 127/16 in order to free up mostly unused resources in that portion of the IPv4 address pool. In studying this lead, I discovered that there are at least a few similar ongoing IETF Drafts being proposed by the "IPv4 Unicast 

Extensions Project":


     A.    Unicast Use of the Formerly Reserved 0/8 (Version 00: 2021-11-07):

https://datatracker.ietf.org/doc/html/draft-schoen-intarea-unicast-0-00

     B.    Unicast Use of the Formerly Reserved 127/8 (Version 00: 2021-11-08)

https://datatracker.ietf.org/doc/html/draft-schoen-intarea-unicast-127-00

     C.    Unicast Use of the Lowest Address in an IPv4 Subnet (Version 00: 
2021-10-20)
https://datatracker.ietf.org/doc/html/draft-schoen-intarea-unicast-lowest-address-01

     D.    Unicast Use of the Formerly Reserved 240/4 (Version 00: 2021-10-19)

https://datatracker.ietf.org/doc/html/draft-schoen-intarea-unicast-240-01

1)    In particular, the last Draft deals with the same netblock that our team 
has been reporting since 2016:

         Adaptive IPv4 Address Space (Version 00: 2016-12-14)

https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space

Since we were advised several times in the past that IPv4 related topics were no longer active IETF tasks, we have been only updating our drafts 
as lab notes about our progress. Upon a quick scan, I believe that our scheme, nicknamed EzIP (Phonetic for Easy IPv4) is more concise and capable 
than, while avoiding most of the considerations expressed by,  the other drafts.


2)    Now that the correlation have been established, may I request to include our proposal with the above discussions so that we 

can have a more efficient and productive use of our resources?




Regards,



Abe (2021-12-03 18:09 EST)
VP Engineering
Avinta Communications
Milpitas CA 95035 USA
eMail: ayc...@avinta.com
WebSite: www.Avinta.com



   Virus-free. www.avast.com 


<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

[Brian E Carpenter]

On 03-Dec-21 11:17, Dino Farinacci wrote:
You missed the point maybe. Common functions should be performed at the 

waist so applications don’t have to duplicate functionality.

Hmm. Logic compels me to offer an alternative:

Common functions should be performed by a shared library so applications don’t 
have to duplicate functionality.

I think both statements are true, and need to be read in conjunction with:
"The function in question can completely and correctly be implemented only with the 
knowledge and help of the application standing at the endpoints of the communication 
system. Therefore, providing that questioned function as a feature of the communication 
system itself is not possible. (Sometimes an incomplete version of the function provided 
by the communication system may be useful as a performance enhancement.)"
[Saltzer et al, doi.org/10.1145/357401.357402]

The user doesn't care whether the common functions are provided in the network 
or in the end hosts. We don't need to artificially force common functions into 
the network.

Restoration of connectivity is a common function, often provided by host 
software.

   Brian



Dino


On Dec 2, 2021, at 2:08 PM, Templin (US), Fred L  
wrote:



Your diagram is missing a critical layer – the adaptation layer.

*From:*Int-area [mailto:int-area-boun...@ietf.org] *On Behalf Of *Dino 

Farinacci

*Sent:* Thursday, December 02, 2021 1:05 PM
*To:* Stewart Bryant 
*Cc:* int-area@ietf.org; Dirk Trossen 
*Subject:* Re: [Int-area] Side meeting follow-up: What exact features do we 
want from the Internet?

The key question that I would ask Dino is whether these need to be 

addressed at the network layer?


Yes, because of this architectural principle:






On 1 Dec 2021, at 22:18, Dino Farinacci mailto:farina...@gmail.com>> wrote:

Here's my single feature request the network layer should provide:

(1) I want to be connected ALL THE TIME, I want my computer to 

use all its links, either cabled or radio, ALL THE TIME.



It can do this by treating these as independent links with different 
addresses and bind them in the application or through some OS service.

Its too much complexity for the app. The app is talking to one place and 
shouldn't know where it is. Hence the network layer should do this.





(2) I do not want to turn on and off wifi to get my device/computer to 
connect when it is currently not connected. The network layer should do all 
this for me.


Is that a network layer problem or an OS problem?

Yes, its a network layer problem. The OS is just an implmentation of a 

network stack.






(3) I want it easy for people to find me (my IP address), so I 
don't want multiple addresses from the user level. I want one device 
ID, EID, host address, whatever you want to call it. I want you to "ping ".



It is important that people can find you/your device, but I am not 

convinced they need to find you by historic IP address.


I used this example (at the network layer) due to the audience of the list. 
What I really want to know is Stewart's crypto wallet address because I want to 
send you a donation. That is addressing at a specific app level.



“Pinging” Dino’s computer does not have to 

happen directly at the network layer to find out that it is alive. To test


Right but if I want to debug where my crypto transaction is going (I want it to 
go from my computer to your computer) then I have to go down a level (to the 
network layer), that is as an engineer (not high-level user) to determine an 
issue or understand performance.



*a* path to Dino’s computer sure you need the address that 

that path responds to, but I am not convinced that it is simpler if the address 
on that network is the same as the address on all of the other networks to 
which it is attached.


There is one network. You are one human being with 2 names. I can call 
you Stewart or Mr Bryant. It doesn't matter you will respond but wouldn't 
it be better if I called you "my-friend" and packets can go to either Steward or Mr Bryant?


I can tell you could react that this is a stretch, but you get what I'm trying 
to get across. The physical connection should not matter to the app. And don't 
forget the physical connection goes up and down, it gets fast and slow, it gets 
address (i.e. locator) changes. That should be damped out from the app.




Yes, I want host multi-homing and mobility. And I want it to work 
seamlessly.


Yes, I agree but I am not convinced we need to solve this by adding the 
complexity in L3 and hence through out the whole of the Internet rather than 
further up the protocol stack.

You always have to add something to get something. And what you add can be 
simple. Just have to make choices very very carefully.

Dino




Stewart




Speaking as a user,
Dino


On Dec 1, 2021, at 12:52 AM, Dirk Trossen 

Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address

[Brian E Carpenter]

On 14-Aug-21 06:49, Seth David Schoen wrote:
> Carsten Bormann  wrote:
...
>> a cost that is better invested in accelerating the migration to IPv6.
> 
> IETF could deny the community a forum in which to form a consensus
> about how IPv4 can usefully evolve.  

"The IAB expects that the IETF will stop requiring IPv4 compatibility in new or 
extended protocols. Future IETF protocol work will then optimize for and depend 
on IPv6." [https://www.iab.org/2016/11/07/iab-statement-on-ipv6/] So any IETF 
effort
on "evolving" IPv4 is really not on the radar. Patching it up operationally is
in scope, of course. That's what you seem to be proposing.

> But it can't force everyone to
> spend an equivalent amount of energy on doing one particular other
> thing, like "accelerating the migration to IPv6".  As we discussed in
> our message responding to Brian Carpenter and Andrew Sullivan, that is a
> false dilemma. 

Not really; the total effort available to get documents through the IETF
process is a finite resource. (Not the effort to create -00 drafts, which
appears to be an infinite resource, but the process that follows, which is
already far too slow because the pipeline is full. Actual the Suez Canal
is a better analogy, because each step in the process works like a basin
and a lock, with finite throughput.)

> Neglecting or abandoning IPv4 isn't an IPv6 transition
> strategy.

As I've been saying for 15+ years, we don't have a transistion strategy,
we have a co-existence strategy. That's indeed orthogonal to a marginal
extra supply of IPv4 addresses.

 Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address

[Brian E Carpenter]

> My understanding is that IETF's role is as a
> steward of network-wide value, which is why I thought this might
> interest IETF.

Not quite. The mission is "to make the Internet work better" and
affecting the sales value of 32 bit numbers is not really the same
thing, especially since 128 bit numbers are already much cheaper. 

Regards
   Brian Carpenter

On 03-Aug-21 21:43, John Gilmore wrote:
>> Do I understand correctly, that you are proposing that all hosts,
>> routers, firewalls, middle boxes, etc. on the Internet, be updated in
>> order to get a single extra IP address per subnet?  ...
>> To me this fails the cost benefit analysis.
> 
> You may be right (see below).  One confounding factor is that the
> lowest-address draft is the first of a set of upcoming drafts that
> propose small, easy improvements in IPv4.  This set of changes, in
> aggregate, will be worth implementing, because they create hundreds of
> millions of newly usable addresses, worth billions of dollars at current
> prices.  If the cost-vs-benefit is worth doing for ANY ONE of these
> changes, or for any subset of these changes, then the deployment effort
> may as well include the other, smaller, improvements, which will come
> for very close to free.
> 
> I agree that the "lowest address" protocol change is only likely to
> produce tens of millions of newly usable addresses, creating only
> perhaps $250M to $500M of benefits at current prices.  That alone might
> not be worth doing, particularly since predicting FUTURE prices of IPv4
> addresses is risky.  But let's look at the costs.  The end-user cost of
> updating can be zero because it can be deferred until equipment is
> naturally upgraded for other reasons.  Nobody would buy a new router to
> get this feature, but eventually almost everybody buys a new router.  Or
> installs the latest OS release.  The change is completely compatible
> with existing networks, since the lowest addresses are currently not
> known to be used for anything and have been declared obsolete in IETF
> standards for decades.  This makes the deployment risk very low.
> 
> So I expect the main cost would be for each vendor to make and test
> small patches to their existing IPv4 implementations, and then include
> those changes as part of their next release or product.  Our team
> successfully patched both Linux and BSD over a few weeks, and
> interoperated them successfully.  Based on that experience, I estimate
> implementation costs to major IPv4 vendors to be under $10M in total.
> By 5 to 10 years after adoption, the improvement would be everywhere,
> and will probably have paid off about 25-to-1.  I agree that the people
> incurring the costs of this proposal are not the people who end up
> getting the benefit of the IP addresses; the benefit goes to the
> vendors' customers, benefiting the vendors indirectly.  So the
> cost-benefit tradeoff might be more societal (or network-wide) than
> individual or corporate.  My understanding is that IETF's role is as a
> steward of network-wide value, which is why I thought this might
> interest IETF.
> 
>   John Gilmore
>   IPv4 Unicast Extensions
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address

[Brian E Carpenter]

> As we
> will describe in more detail in future posts, we expect these changes will
> create enormous economic value, and they are not intended as an attack on
> the IPv6 transition.

Most of the consolidation of IPv4 usage by ISPs in recent years has been
in the deployment of CGNs and aggressive address sharing. As far as I can
tell, most consolidation of IPv4 usage within enterprises has been based
on Net 10. So I am not at all clear where this economic value would be,
or why the IETF should even care about it. 

Regards
   Brian

On 02-Aug-21 17:59, Seth David Schoen wrote:
> Hi,
> 
> John Gilmore, Dave Taht and I have proposed a recent Internet-Draft that
> relates to the Internet Area.  We hope you'll read it and discuss it:
> 
>   https://datatracker.ietf.org/doc/draft-schoen-intarea-lowest-address/
> 
>   With ever-increasing pressure to conserve IP address space on the
>   Internet, it makes sense to consider where relatively minor changes
>   can be made to fielded practice to improve numbering efficiency.  One
>   such change, proposed by this document, is to increase the number of
>   unicast addresses in each existing subnet, by redefining the use of
>   the lowest-numbered (zeroth) host address in each IPv4 subnet as an
>   ordinary unicast host identifier, instead of as a duplicate segment-
>   directed broadcast address.
> 
> Our IPv4 Unicast Extensions team is working on several related
> proposals for improving address space utilization, of which this is
> the first.  We are also editing I-Ds for each of the other proposals
> and will upload them to the datatracker when they're ready.  Each
> proposal changes the status of some particular unused IPv4 addresses
> in order to make more address space available, and each has involved
> experimentation with real-world operating systems to explore the ease
> with which the proposed change can be made and learn about its
> consequences.
> 
> These proposals would, if adopted and deployed, produce another tens
> to hundreds of millions of IPv4 addresses usable for unicast traffic.
> This can be accomplished by making quite small, easy to make, easy to
> test, incremental changes in popular TCP/IP implementations.  (The Lowest
> Address patch for Linux is less than 10 lines long, and the BSD patch is
> similar.  They interoperate with each other and are already addressable
> by unpatched implementations when distant from the local subnet.)  As we
> will describe in more detail in future posts, we expect these changes will
> create enormous economic value, and they are not intended as an attack on
> the IPv6 transition.
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> .
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] draft-eckert-intarea-functional-addr-internets-00.txt

[Brian E Carpenter]

I am told that the URL below is broken. 

Sorry, my bad. Try https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-849.pdf

The citation is Marcelo Bagnulo Braun and Jon Crowcroft, SNA: Sourceless 
Network Architecture, Technical Report Number 849, Computer Laboratory, 
University of Cambridge (2014), UCAM-CL-TR-849, ISSN 1476-2986.

Regards
   Brian Carpenter
On 14-Jul-21 10:25, Brian E Carpenter wrote:
> On 13-Jul-21 17:57, Stewart Bryant wrote:
>> An interesting draft Toerless.
>>
>> From a background POV it is worth noting ISO 8473 which is in deployment 
>> with multi-type variable length address.
> 
> Pretty ugly and limited though, and as I understand it the major 
> (unclassified) deployment, in the airline trade, is trying to migrate away. I 
> have no idea if there are classified deployments, but if so, I expect they 
use the non-variable GOSIP format.
> 
> I think ISO 8473 is a pretty good model of how not to do it.
> 
>> It is also worth noting that SA is different from DA to the extent that 
> it may not belong in the network layer header of the outgoing packet. The 
> SA is arguably a function of the payload and the application. Indeed some 
> MPLS OAM solutions do just that by making the return address implicit in the 
> arrival LSP, or a parameter in a payload TLV. SA as in IP is arguably 
> just a convenience for a simplified method of operating an application.
> 
> My favourite article on that topic is 
> https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-849.pdf
> 
>Brian
> 
>>
>> Stewart
>>
>> Sent from my iPad
>>
>>> On 13 Jul 2021, at 00:05, Toerless Eckert  wrote:
>>> Dear Int-area
>>>
>>> As attached below, i have written up an idea about why and how 
>>> variable-length
>>> addresses in the network layer would be useful for many limited domain 
> internetworks,
>>> but also how they could provide a simple and easily extensible framework to
>>> add additional semantics (the likes of multicast, BIER, ICN), and also 
> make it easier 
>>> to express the programmability that SRv6 introduced.
>>>
>>> Would very much welcome discussion/feedback, and will be asking for a 
slot
>>> to present/discuss this int-area 111.
>>>
>>> Note that the -00 writeup is mostly inspirational for what i think the 
> cool
>>> things one could do with it are and to explain the concepts.
>>>
>>> Obviously, if/when there is interest in this
>>> direction, the harder work of figuring out how to best introduce this
>>> incrementally, and ideally backward compatible into existing networks 
wold
>>> be the next big set of items to work out.
>>>
>>> Cheers
>>>Toerless
>>>
>>> On Mon, Jul 12, 2021 at 01:00:25PM -0700, internet-dra...@ietf.org wrote:
>>>> A new version of I-D, draft-eckert-intarea-functional-addr-internets-00.txt
>>>> has been successfully submitted by Toerless Eckert and posted to the
>>>> IETF repository.
>>>>
>>>> Name:draft-eckert-intarea-functional-addr-internets
>>>> Revision:00
>>>> Title:Functional Addressing (FA) for internets with Independent 
>>>> Network Address Spaces (IINAS)
>>>> Document date:2021-07-12
>>>> Group:Individual Submission
>>>> Pages:30
>>>> URL:
>>>> https://www.ietf.org/archive/id/draft-eckert-intarea-functional-addr-internets-00.txt
>>>> Status: 
>>>> https://datatracker.ietf.org/doc/draft-eckert-intarea-functional-addr-internets/
>>>> Htmlized:   
>>>> https://datatracker.ietf.org/doc/html/draft-eckert-intarea-functional-addr-internets
>>>>
>>>>
>>>> Abstract:
>>>>   Recent work has raised interest in exploring network layer addressing
>>>>   that is more flexible than fixed-length addressing as used in IPv4
>>>>   (32 bit) and IPv6 (128 bit).
>>>>
>>>>   The reasons for the interest include both support for multiple and
>>>>   potentially novel address semantics, but also optimizations of
>>>>   addressing for existing semantics such as unicast tailored not for
>>>>   the global Internet but to better support private networks / limited
>>>>   domains.
>>>>
>>>>   This memo explores in the view of the author yet little explored
>>>>   reasons for more flexible addresses namely the problems and
>>>>   opportunities for Internetworking with Independent Network Address
>

Re: [Int-area] draft-eckert-intarea-functional-addr-internets-00.txt

[Brian E Carpenter]

On 13-Jul-21 17:57, Stewart Bryant wrote:
> An interesting draft Toerless.
> 
> From a background POV it is worth noting ISO 8473 which is in deployment with 
> multi-type variable length address.

Pretty ugly and limited though, and as I understand it the major (unclassified) 
deployment, in the airline trade, is trying to migrate away. I have no idea if 
there are classified deployments, but if so, I expect they use the non-variable 
GOSIP format.

I think ISO 8473 is a pretty good model of how not to do it.

> It is also worth noting that SA is different from DA to the extent that 
it may not belong in the network layer header of the outgoing packet. The 
SA is arguably a function of the payload and the application. Indeed some 
MPLS OAM solutions do just that by making the return address implicit in the 
arrival LSP, or a parameter in a payload TLV. SA as in IP is arguably 
just a convenience for a simplified method of operating an application.

My favourite article on that topic is 
https://www.cl.cam.ac.uk/techreports/FUCAM-CL-TR-849.pdf

   Brian

> 
> Stewart
> 
> Sent from my iPad
> 
>> On 13 Jul 2021, at 00:05, Toerless Eckert  wrote:
>> Dear Int-area
>>
>> As attached below, i have written up an idea about why and how 
>> variable-length
>> addresses in the network layer would be useful for many limited domain 
internetworks,
>> but also how they could provide a simple and easily extensible framework to
>> add additional semantics (the likes of multicast, BIER, ICN), and also 
make it easier 
>> to express the programmability that SRv6 introduced.
>>
>> Would very much welcome discussion/feedback, and will be asking for a slot
>> to present/discuss this int-area 111.
>>
>> Note that the -00 writeup is mostly inspirational for what i think the 
cool
>> things one could do with it are and to explain the concepts.
>>
>> Obviously, if/when there is interest in this
>> direction, the harder work of figuring out how to best introduce this
>> incrementally, and ideally backward compatible into existing networks wold
>> be the next big set of items to work out.
>>
>> Cheers
>>Toerless
>>
>> On Mon, Jul 12, 2021 at 01:00:25PM -0700, internet-dra...@ietf.org wrote:
>>> A new version of I-D, draft-eckert-intarea-functional-addr-internets-00.txt
>>> has been successfully submitted by Toerless Eckert and posted to the
>>> IETF repository.
>>>
>>> Name:draft-eckert-intarea-functional-addr-internets
>>> Revision:00
>>> Title:Functional Addressing (FA) for internets with Independent 
>>> Network Address Spaces (IINAS)
>>> Document date:2021-07-12
>>> Group:Individual Submission
>>> Pages:30
>>> URL:
>>> https://www.ietf.org/archive/id/draft-eckert-intarea-functional-addr-internets-00.txt
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-eckert-intarea-functional-addr-internets/
>>> Htmlized:   
>>> https://datatracker.ietf.org/doc/html/draft-eckert-intarea-functional-addr-internets
>>>
>>>
>>> Abstract:
>>>   Recent work has raised interest in exploring network layer addressing
>>>   that is more flexible than fixed-length addressing as used in IPv4
>>>   (32 bit) and IPv6 (128 bit).
>>>
>>>   The reasons for the interest include both support for multiple and
>>>   potentially novel address semantics, but also optimizations of
>>>   addressing for existing semantics such as unicast tailored not for
>>>   the global Internet but to better support private networks / limited
>>>   domains.
>>>
>>>   This memo explores in the view of the author yet little explored
>>>   reasons for more flexible addresses namely the problems and
>>>   opportunities for Internetworking with Independent Network Address
>>>   Spaces (IINAS).
>>>
>>>   To better enable such internetworks, this memo proposes a framework
>>>   for a Functional Addressing model.  This model also intends to
>>>   support several other addressing goals including programmability and
>>>   multiple semantics.
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>
>> -- 
>> ---
>> t...@cs.fau.de
>>
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-eckert-intarea-functional-addr-internets-00.txt

[Brian E Carpenter]

Hi all,

I think there's a case to be made that layer 3 itself is the problem, not the 
details of an addressing scheme [1]. (That reference predated QUIC, but I think 
the main conclusions stand.) A more radical solution like NDN [2] may be needed.

[1] https://doi.org/10.1145/2602204.2602215, a.k.a. 
https://www.cs.auckland.ac.nz/~brian/CCR-201404-IPaddrHarmful.pdf

[2] https://named-data.net

Regards
   Brian Carpenter

On 13-Jul-21 08:00, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> Title   : Functional Addressing (FA) for internets with 
> Independent Network Address Spaces (IINAS)
> Author  : Toerless Eckert
>   Filename: draft-eckert-intarea-functional-addr-internets-00.txt
>   Pages   : 30
>   Date: 2021-07-12
> 
> Abstract:
>Recent work has raised interest in exploring network layer addressing
>that is more flexible than fixed-length addressing as used in IPv4
>(32 bit) and IPv6 (128 bit).
> 
>The reasons for the interest include both support for multiple and
>potentially novel address semantics, but also optimizations of
>addressing for existing semantics such as unicast tailored not for
>the global Internet but to better support private networks / limited
>domains.
> 
>This memo explores in the view of the author yet little explored
>reasons for more flexible addresses namely the problems and
>opportunities for Internetworking with Independent Network Address
>Spaces (IINAS).
> 
>To better enable such internetworks, this memo proposes a framework
>for a Functional Addressing model.  This model also intends to
>support several other addressing goals including programmability and
>multiple semantics.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-eckert-intarea-functional-addr-internets/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-eckert-intarea-functional-addr-internets-00
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] Fwd: I-D Action: draft-carpenter-6man-rfc6874bis-01.txt

[Brian E Carpenter]

FYI, this will be discussed in 6MAN but may be of wider interest. It will also 
be mentioned in the ART Area meeting, and of course there needs to be some 
external liaison too.

   Brian Carpenter & Bob Hinden

 Forwarded Message 
Subject: I-D Action: draft-carpenter-6man-rfc6874bis-01.txt
Date: Sun, 11 Jul 2021 13:57:06 -0700
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Representing IPv6 Zone Identifiers in Address 
Literals and Uniform Resource Identifiers
Authors : Brian Carpenter
  Robert M. Hinden
Filename: draft-carpenter-6man-rfc6874bis-01.txt
Pages   : 11
Date: 2021-07-11

Abstract:
   This document describes how the zone identifier of an IPv6 scoped
   address, defined as  in the IPv6 Scoped Address Architecture
   (RFC 4007), can be represented in a literal IPv6 address and in a
   Uniform Resource Identifier that includes such a literal address.  It
   updates the URI Generic Syntax specification (RFC 3986) accordingly,
   and obsoletes RFC 6874.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-rfc6874bis-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-lhan-problems-requirements-satellite-net-00.txt

[Brian E Carpenter]

Alexander,

As the tracker shows, that RFC was published in the Independent Submission 
stream, not the IETF stream. There are indeed many cases of non-IETF protocols 
being published as Informational RFCs, but today that would always be in the 
Independent stream. The "status of this memo" section is then 
quite explicit, e.g.:
https://www.rfc-editor.org/rfc/rfc8799.html#name-status-of-this-memo

That is of course a precedent. 

Regards
   Brian Carpenter

On 10-Jul-21 03:02, Alexander Vainshtein wrote:
> Brian, Stewart and all,
> RFC 2804  notwithstanding, IETF has published RFC 3924 
>   on Cisco LI Architecture.
> This is not a formal contradiction, since 3924 has been published as 
> Informational.
> Can this be used as a precedent?
> 
> 
> 
> 
> Get Outlook for Android 
> 
> --
> *From:* rtgwg  on behalf of Brian Carpenter 
> 
> *Sent:* Friday, July 9, 2021, 10:25
> *To:* Stewart Bryant
> *Cc:* Lin Han; i...@ietf.org; INT Area; sa...@jiscmail.ac.uk; UTTARO, JAMES; 
> rt...@ietf.org
> *Subject:* [EXTERNAL] Re: [Int-area] New Version Notification for 
> draft-lhan-problems-requirements-satellite-net-00.txt
> 
> The IETF position on LI is not exactly that it's anathema, but that 
we will not standardise *any* intercept techniques, legal or otherwise. RFC 
2804.
> 
> 
> Regards,
>     Brian Carpenter
>     (via tiny screen & keyboard)
> 
> On Fri, 9 Jul 2021, 18:33 Stewart Bryant, mailto:stewart.bry...@gmail.com>> wrote:
> 
> Unfortunately LI is not our call.
> 
> I know the IETF finds it an anathema but it is an unspoken (in IETF) 
> reality of the telecommunications industry.
> 
> The concept of a huge number of highly portable, highly directional, 
> microwave links that are then relayed opaquely to a foreign country 
is going to delight some agencies and give heartburn to their colleagues in 
other parts of the same agency cluster.
> 
> I think that we can all postulate how this would (will) be solved in 
> a mega-cluster owned by a large ITU region 2 country, or a particularly large 
> Asian country but I assume we want to design a global / universal system 
> rather than one that will otherwise inevitably be partitioned due to 
> geo-political security concerns.
> 
> Stewart
> 
> Sent from my iPad
> 
> 
> 
> 
> Notice: This e-mail together with any attachments may contain information of 
> Ribbon Communications Inc. and its Affiliates that is confidential and/or 
> proprietary for the sole use of the intended recipient. Any review, 
> disclosure, reliance or distribution by others or forwarding without express 
> permission is strictly prohibited. If you are not the intended recipient, 
> please notify the sender immediately and then delete all copies, including 
> any attachments.
> 
> 
> Notice: This e-mail together with any attachments may contain information of 
> Ribbon Communications Inc. and its Affiliates that is confidential and/or 
> proprietary for the sole use of the intended recipient. Any review, 
> disclosure, reliance or distribution by others or forwarding without express 
> permission is strictly prohibited. If you are not the intended recipient, 
> please notify the sender immediately and then delete all copies, including 
> any attachments.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [v6ops] Proxy function for PTB messages on the tunnel end

[Brian E Carpenter]

On 25-Mar-21 03:41, Joseph Touch wrote:
>> On Wed, 24 Mar 2021, 07:53 Vasilenko Eduard, > <mailto:vasilenko.edu...@huawei.com> <mailto:vasilenko.edu...@huawei.com>> 
>> wrote:
> ...
>> On Mar 23, 2021, at 8:47 PM, Brian E Carpenter > <mailto:brian.e.carpen...@gmail.com>> wrote:
>>
>>> Tunnel packets *are* explicitly addressed to a node, so tunnel endpoints 
>>> are performing host functions on packets. If those host functions being 
>>> performed on tunnel packets at the tunnel endpoints require buffers, then 
>>> buffers need to be available.
>>
>> Yes, and tunnel entry points are hosts when they send an encapsulated packet.
> 
> Viewed from inside a tunnel, the tunnel endpoints are both hosts.
> 
>> There's a subtlety though, which is that the device that contains the tunnel 
>> entry point on the downstream side of the packet flow is indeed a router on 
>> the upstream side. Conversely,
>> the device that contains the tunnel exit point is a host on the upstream 
>> side and a router on the downstream side.
> 
> I disagree; a tunnel is a link. That link can easily be host-host.

Agreed. In that case, the prefixes reachable by the tunnel will show up in the 
host's route table, and the tunnel offers whatever MTU it can. In the general 
case the devices containing the TEPs will be routers and they will usually 
participate in a routing protocol for the prefixes reachable via the tunnel. 

> A host that is router-capable (many OSes have a flag to ‘forward IP’ or not) 
> can have forwarding disabled (host-only mode) and use tunnels just fine.
> 
>> Which is why the MTU for packets inside the tunnel is no business of anyone 
>> upstream or downstream of the tunnel.
> 
> Agreed…
> 
> Though I would appreciate your thoughts on how to handle the errors in 
> RFC2473 as noted in draft-tunnels.

As they say in the British Parliament, I require notice of that question. I 
need to re-read the draft.

   Brian
> 
> Joe
> 
>>
>>   Brian
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [v6ops] Proxy function for PTB messages on the tunnel end

[Brian E Carpenter]

On 24-Mar-21 10:27, Mark Smith wrote:
> 
> 
> On Wed, 24 Mar 2021, 07:53 Vasilenko Eduard,  > wrote:
> 
> Hi Joseph,
> 
> __ __
> 
> Currently, vendors have chosen some undisclosed big numbers for the 
> reassembly buffer on the tunnel interface
> 
> Or no buffer at all for tunnels that do not support reassembly.
> 
> That does not create any additional restriction for MTU.
> 
> Nobody did believe (IPv4 or IPv6 – does not matter) that buffer 
> requirements for end nodes are applicable for transit nodes.
> 
> 
> I don't think you're not fully understanding the difference between hosts and 
> routers. I'm guessing you're thinking and imagining them as physical devices. 
> The definitions are actually functional (and the dictionary definition of the 
> word "device" is not a physical device.)
> 
> Outer tunnel packet header DAs are obviously the tunnel end-point IP 
> addresses.
> 
> Which of these definitions from RFC 8200 describes what type of IPv6 node a 
> tunnel end point is?
> 
> " router       a node that forwards IPv6 packets not explicitly
>                 addressed to itself.
> 
>    host         any node that is not a router."
> 
> Tunnel packets *are* explicitly addressed to a node, so tunnel endpoints are 
> performing host functions on packets. If those host functions being performed 
> on tunnel packets at the tunnel endpoints require buffers, then buffers need 
> to be available.

Yes, and tunnel entry points are hosts when they send an encapsulated packet. 
There's a subtlety though, which is that the device that contains the tunnel 
entry point on the downstream side of the packet flow is indeed a router on the 
upstream side. Conversely,
the device that contains the tunnel exit point is a host on the upstream side 
and a router on the downstream side.

Which is why the MTU for packets inside the tunnel is no business of anyone 
upstream or downstream of the tunnel.

   Brian

> 
> Internally, a router as a device (your "transit node") is performing both 
> host and routing functions. The forwarding plane component is:
> 
> "a node that forwards IPv6 packets not explicitly addressed to itself" - a 
> router
> 
> The control plane, and other functions like tunnel endpoints, in a router as 
> a device, is:
> 
> "any node that is not a router" - a host
> 
> This is the same for IPv4:
> 
> RFC791, 
> 
> "The internet protocol provides for transmitting blocks of data called 
> datagrams from sources to destinations, where sources and destinations are 
> *hosts* identified by  fixed length addresses."
> 
> (And as another example of device verses function. If you buy a router as a 
> device from a router vendor (rack mount, multiple interfaces, limited LCD/LED 
> display, console port), and then use it as a BGP Route Reflector, such that 
> it never forwards packets because it is never in a forwarding path, is it 
> still a "router"? It might look like one, but it is only performing host 
> packet processing of the BGP protocol.)
> 
> 
> 
> 
> Your liberty to apply the requirements and terminology of one to the 
> other is not a good idea.
> 
> draft-ietf-intarea-tunnels propose to decrease reassembly buffer to 
> “typical host EMTU_R (1500B) minus tunnel outer headers overhead” that would 
> cause additional fragmentation.
> 
> __ __
> 
> As the compromise:
> 
> Could you change the default for “draft-ietf-intarea-tunnels Tunnel MTU” 
> (reassembly buffer) to 9k? (to reflect reality)
> 
> I would still be not happy in the mail to any alias about calling 
> parameters of transit node buffer by the terminology of end node buffer.
> 
> But if you would not create additional fragmentation – I would not have 
> any complains in my draft in regards to draft-ietf-intarea-tunnels. 
> 
> It could be the resolution.
> 
> __ __
> 
> Well, probably it is not a good compromise, because you have the logic 
> through all your document. 9k (reality) would protrude out of your logic.
> 
> The logic itself is good. It is broken because the most basic assumption 
> is wrong (before you did apply any logic).
> 
> __ __
> 
> *The Data Plane on transit nodes should not behave*
> 
> *as the Control Plane on transit nodes or Transport Layer on end 
> nodes!*
> 
> It was the wrong assumption initially. Buffers should be different. Names 
> should be different. Unification here is not possible.
> 
> It would be rejected by vendors anyway because reassembly is expensive, 
> the one who would increase it – would get a competitive disadvantage.
> 
> It is easy to translate additional reassembly to $$ losses.
> 
> __ __
> 
> Eduard
> 
> *From:*Joseph Touch [mailto:to...@strayalpha.com 
> ]
> *Sent:* Tuesday, March 23, 2021 10:44 PM
> *To:* Vasilenko Eduard  

Re: [Int-area] [v6ops] Proxy function for PTB messages on the tunnel end

[Brian E Carpenter]

On 24-Mar-21 09:52, Vasilenko Eduard wrote:

> The terms “source node” and “destination node” are used in RFC8200 but not 
> defined in Sec 2. They are clearly hosts that originate IPv6 packets and 
> hosts that consume IPv6 packets, respectively.

In fact "destination node" is more than that, since in some contexts it is not 
the final destination (that presumably uses the transport header and the 
payload) but an intermediate router in the case of source routing, including 
SRV6.

Agreed that RFC 8200 does not discuss tunnel end points, which are legitimately 
also on the path. So RFC 2473 is definitive until updated.

By the way, please avoid colour in IETF messages. Everything needs to be clear 
for text/plain readers.

Regards
Brian

-
> Hi Joseph,
> 
>  
> 
> Currently, vendors have chosen some undisclosed big numbers for the 
> reassembly buffer on the tunnel interface
> 
> Or no buffer at all for tunnels that do not support reassembly.
> 
> That does not create any additional restriction for MTU.
> 
> Nobody did believe (IPv4 or IPv6 – does not matter) that buffer requirements 
> for end nodes are applicable for transit nodes.
> 
> Your liberty to apply the requirements and terminology of one to the other is 
> not a good idea.
> 
> draft-ietf-intarea-tunnels propose to decrease reassembly buffer to “typical 
> host EMTU_R (1500B) minus tunnel outer headers overhead” that would cause 
> additional fragmentation.
> 
>  
> 
> As the compromise:
> 
> Could you change the default for “draft-ietf-intarea-tunnels Tunnel MTU” 
> (reassembly buffer) to 9k? (to reflect reality)
> 
> I would still be not happy in the mail to any alias about calling parameters 
> of transit node buffer by the terminology of end node buffer.
> 
> But if you would not create additional fragmentation – I would not have any 
> complains in my draft in regards to draft-ietf-intarea-tunnels.
> 
> It could be the resolution.
> 
>  
> 
> Well, probably it is not a good compromise, because you have the logic 
> through all your document. 9k (reality) would protrude out of your logic.
> 
> The logic itself is good. It is broken because the most basic assumption is 
> wrong (before you did apply any logic).
> 
>  
> 
> *The Data Plane on transit nodes should not behave*
> 
> *as the Control Plane on transit nodes or Transport Layer on end nodes!*
> 
> It was the wrong assumption initially. Buffers should be different. Names 
> should be different. Unification here is not possible.
> 
> It would be rejected by vendors anyway because reassembly is expensive, the 
> one who would increase it – would get a competitive disadvantage.
> 
> It is easy to translate additional reassembly to $$ losses.
> 
>  
> 
> Eduard
> 
> *From:*Joseph Touch [mailto:to...@strayalpha.com]
> *Sent:* Tuesday, March 23, 2021 10:44 PM
> *To:* Vasilenko Eduard 
> *Cc:* v6...@ietf.org; int-area 
> *Subject:* Re: Proxy function for PTB messages on the tunnel end
> 
>  
> 
>  
> 
> 
> 
> On Mar 23, 2021, at 12:10 PM, Vasilenko Eduard 
> mailto:vasilenko.edu...@huawei.com>> wrote:
> 
>  
> 
> Hi Joseph,
> 
> I am not much interested to discuss IPv4 now. (despite that 2 MTUs for 
> one interface is absent there too)
> 
> Let’s look at your reference to RFC 8200.
> 
> Section 4.5: unlike IPv4, fragmentation in IPv6 is performed only by 
> source nodes, not by routers along a packet's delivery path
> 
> It means that all these discussions about fragmentation and reassembly 
> are not related to transit nodes. It is for the “source and destination 
> nodes”.
> 
>  
> 
> Agreed.
> 
> 
> The better terminology is “transit node”, “destination node” – like it is 
> in RFC 8200, not “host” or “router”.
> 
>  
> 
> Please see section 2 of RFC8200 (color added by me):
> 
>  
> 
> 
> 2 .  Terminology
> 
>  
> 
>  
> 
>    node a device that implements IPv6.
> 
>  
> 
>    *router*   a node that forwards IPv6 packets not explicitly
> 
>     addressed to itself.  (See Note below.)
> 
>  
> 
>    *host* any node that is not a router.  (See Note below.)
> 
>  
> 
> The term “transit node” does no appear in RFC8200.
> 
>  
> 
> The terms “source node” and “destination node” are used in RFC8200 but not 
> defined in Sec 2. They are clearly hosts that originate IPv6 packets and 
> hosts that consume IPv6 packets, respectively.
> 
>  
> 
> In an IPv6 tunnel, the tunnel ingress emits new packets with IP headers it 
> adds using its IP address. That makes it a source node. Same for how the 
> egress consumes those packets. 
> 
>  
> 
> From the perspective of the tunnel path, the ingress and egress are hosts and 
> intermediate hop relays are routers.
> 
>  
> 
> From the perspective of the overall path, the tunnel is a link, either 
> host/host, host/router, router/host, or router/router. A tunnel is not itself 
> a router, however.
> 
>  
> 
>  
> 
> 

Re: [Int-area] [v6ops] Proxy function for PTB messages on the tunnel end

[Brian E Carpenter]

On 23-Mar-21 08:32, Vasilenko Eduard wrote:
...
> What to do if one could not push the traffic source to decrease MTU because 
> it is already 1280 (minimum)?

Nothing. Any tunnel MUST do whatever it has to do to carry a 1280 byte packet. 
That is by definition always the tunnel's problem and never the host's problem.

   Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

[Brian E Carpenter]

On 02-Mar-21 22:20, Toerless Eckert wrote:
> Hi Brian,
> 
> On Tue, Mar 02, 2021 at 09:08:10AM +1300, Brian E Carpenter wrote:
>> There is work on supporting shorter address lengths in limited domains where 
>> that is sufficient. I don't think we have a viable use case yet for longer 
>> addresses, although we do have a need for 3GPP operators to support prefixes 
>> shorter than /64, but that's a deployment issue, not a standards issue.
>>
>> (BIER doesn't strike me as such a use case; an overlay is the natural 
>> solution and it's roughly what Rick Boivie and others proposed in XCAST 20 
>> years ago, as eventually recorded in RFC5058. I'm fairly uninformed about 
>> ICN but again it seems to me that an overlay is the natural solution and 
>> blending it into the network layer would be spaghetti engineering.)
> 
> How do you come to that conclusion ? IP Multicast where it is business 
> relevant is
> also not deployed as an overlay, and neither is BIER in the SP deployments 
> where
> the original use-cases come from.

Sure. I co-authored the "limited domains" RFC, right? But when you look at 
Internet-wide deployment (which is surely the target for ICN, and was the 
original target for multicast), an overlay seems to impose itself.

> But IMHO underlay vs. overlay is just a red herring: Any hop-by-hop 
> forwarding protocol
> ultimately is some form of overlay/underlay to some other and overlays are 
> always
> an important tool for early adoption. That does not change the need to support
> flexible addrss length in one hop-by-hop protocol so that it can become a 
> common
> framwork for multiple semantics.

When 128 bits runs out, yes. 

Oh, I should point out that we did have a run at this topic a few years ago: 
https://tools.ietf.org/html/rfc1888, especially sections 4 and 5.

Brian

> 
> Of course, if i only use CPU-forwarding overlays, the cost of duplicating 
> system
> infrastructure by reinventing the whole protocol stack goes down. E.g.: if i
> could build a service out of let's say only BIER, and forwarder and end-points
> is all software i own, i could clone everything from IPv6, change length to 
> 256
> and call it a day. But we do know that actual solutions need access to all 
> semantics,
> as is also obvious from unicast + multicast example.
> 
> Whereas BIER duplicated the network header and is therefore a bit like the VM 
> approach DCs, where 90% of code is duplicated (OS/libs), the integrated 
> multi-semantic
> network protocol is like the container approach in DC.
> 
>> It would take but a minute to design a longer-address mechanism for IPv6, 
>> although I don't have space to include it in the margin of this email**. But 
>> it would take many years for it to be widely implemented and deployed, 
>> during which time the Internet would be opaque to such addresses.
> 
> Sure. And i think like the VM/container comparison, duplicating everything
> at network layer when you need a new semantic might even get you 
> started quicker, but over the long term the duplication cost outweights
> this. I would argue this is exactly what we also see in the duplication
> between IPv6 and IPv4. Of course, no one is to blame for this because there
> was a rightfull hope for IPv4 to go away, when we look back at our more
> naive selfs of the 1990th (at least thats what i believed, but that was before
> i was exposed mayorly to all those 90% of limited domain networks you don't
> see if you only "live on the Internet").
> 
>>> We've already seen with SRv6 how more flexible use of addresses can help
>>> solutions.
>>
>> Have we really seen that? How many sites are running production traffic 
>> using SRv6?
>> In any case, 128 bits seem to be largely sufficient for SRv6 purposes, since 
>> the semantics are local.
> 
> I think we need to distinguish a bit between the enabling of opportunities
> that a technology offers and the ability of specific business models of
> operators to absorb and utilize those. Of course we do have more fundamental 
> issues
> wrt. to creating new revenue through new technologies than simply building 
> beter
> network protocols. But better network protocols are IMHO a key building block.
> 
> Cheers
> Toerless
> 
>> Brian
>>
>> ** Basically, use a prefix such as fb00::/8 to indicate an extended address.
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

[Brian E Carpenter]

On 03-Mar-21 01:32, Stewart Bryant wrote:
> 
> 
>> On 1 Mar 2021, at 20:08, Brian E Carpenter > <mailto:brian.e.carpen...@gmail.com>> wrote:
>>
>>
>> It would take but a minute to design a longer-address mechanism for IPv6, 
>> although I don't have space to include it in the margin of this email**. But 
>> it would take many years for it to be widely implemented and deployed, 
>> during which time the Internet would be opaque to such addresses.
>>
>>
>> ** Basically, use a prefix such as fb00::/8 to indicate an extended address.
> 
> Hi Brian
> 
> Basically I think that this fails the backwards compatibility text.

Short answer: that's why the Internet would be opaque to it for many years.

Longer answer: change every router in the universe (exactly what we did to 
achieve the universal deployment of IPv6). At that point, changing the 
ethertype/IP version is really not that different than demultiplexing packets 
by looking at the first byte of the source address.

But I am not seriously advocating any of this. If I'd believed this was a 
viable approach, I would have advocated one of the IPng proposals that extended 
IPv4 addressing in that way.

Brian
 
> It is perfectly legitimate to write an IPv6 forwarder as follows:
> 
> If MACaddress == me and MACtype == IPv6 pass packet to IPv6 forwarder
> 
> In IPv6 forwarder:
> 
> If version == IPv6 and Hop Limit not exceeded send bytes 24 to 39 to address 
> lookup engine
> 
> Wait for address result and forward packet accordingly
> 
> Except that this forwarder would have sent a bunch of random junk to the ALE 
> consisting of some of the SA and maybe some of the DA depending on their 
> sizes.
> 
> So to stop an old and legitimately designed parser being fooled you really 
> have to use a new MAC type and a new version and as soon as you do that you 
> might as well design the packet optimally for the job at hand.
> 
> If the IPv6 designers had followed the strategy of both the Ethernet 
> designers and the ISO8473 designers and put DA before SA then the elegant 
> approach that you and others have  proposed at various times would have 
> worked nicely.
> 
> Best regards
> 
> Stewart
> 
> 
> 
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

[Brian E Carpenter]

Hi Toerless,
On 02-Mar-21 04:33, Toerless Eckert wrote:
> It is somewhat ironic to see how it was IP and IPv6 that where the protocols 
> that where
> successfully enhanced with additional adress semantics not considered when 
> they where designed
> (ok, at last IPv4, but arguably also in a more subtle fashion IPv6). Even 
> though as Stewart
> points out, CLNP would be more easily able to absorb additional semantics 
> because of its
> flexible address length. But of course new semantics are looking for the best 
> model to see
> actual deployments, and that best happens with protocols already most widely 
> deployed.
> 
> Which at the time IP Multicast was designed was obviously IPv4 (at least in 
> the USA where it
> originated), not CLNP.
> 
> So now we're stuck that adopting newer semantics like BIER or ICN natively 
> into IPv6 is
> primarily not possible because of IPv6 fixed address length. Instead, BIER 
> had to do its
> own second network hop-by-ho forwarding protocol/header duplicating all of 
> IPv6 as needed,
> just to have longer addresses, and ICN (hICN) proposing which in by book is 
> really an
> overlay solution to leave IPv6 pretty much untouched. 
> 
> I really don't understand why the IPv6 world has not understood how the most 
> easy way
> to allow for the applicability of IPv6 to grow (especially beyond "just more 
> addresses thn IPv4")
> would be to come up with a backward compatible encap on the wire that would 
> support additional
> address lengths.

There is work on supporting shorter address lengths in limited domains where 
that is sufficient. I don't think we have a viable use case yet for longer 
addresses, although we do have a need for 3GPP operators to support prefixes 
shorter than /64, but that's a deployment issue, not a standards issue.

(BIER doesn't strike me as such a use case; an overlay is the natural solution 
and it's roughly what Rick Boivie and others proposed in XCAST 20 years ago, as 
eventually recorded in RFC5058. I'm fairly uninformed about ICN but again it 
seems to me that an overlay is the natural solution and blending it into the 
network layer would be spaghetti engineering.)

It would take but a minute to design a longer-address mechanism for IPv6, 
although I don't have space to include it in the margin of this email**. But it 
would take many years for it to be widely implemented and deployed, during 
which time the Internet would be opaque to such addresses.

> We've already seen with SRv6 how more flexible use of addresses can help
> solutions.

Have we really seen that? How many sites are running production traffic using 
SRv6? In any case, 128 bits seem to be largely sufficient for SRv6 purposes, 
since the semantics are local.
 
Brian

** Basically, use a prefix such as fb00::/8 to indicate an extended address.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [ih] Fwd: Existing use of IP protocol 114 (any 0-hop protocol)

[Brian E Carpenter]

On 21-Sep-19 17:45, Joe Touch wrote:
> Hi, all,
> 
> I wouldn’t care if this doc used 114 - as long as it is very clear that 114 
> is for *ANY* 0-hop protocol, which means ANYONE else can also use it.
> 
> That means that it might be useful to treat that protocol a little like the 
> experimental TCP codepoints as per RFC6994, i.e., to include a long (4-byte 
> minimum) magic number and tolerate collisions.

Or add a protocol number following this ambiguous protocol number.

(See what I did there?)

Brian

> 
> Joe
> 
>> On Sep 20, 2019, at 9:03 PM, Erik Kline > <mailto:e...@loon.com>> wrote:
>>
>> There's also the matter of whether allocating 114 for this doc would 
>> establish a precedent.
>>
>> On Fri, 20 Sep 2019 at 20:24, Brian E Carpenter > <mailto:brian.e.carpen...@gmail.com>> wrote:
>>
>> On 21-Sep-19 14:11, Joe Touch wrote:
>> > FWIW, there are many registries with such “dead” entries.
>>
>> 114 is a bit special. By definition, all our normal traffic monitoring 
>> techniques will *never* see protocol 114 unless by chance they are installed 
>> on a layer 2 segment where it is in use. So even if no traces anywhere 
>> include it for ten years, we still can't assert that it is out of use. It 
>> seems harder to prove than most negatives :-).
>>
>> > RFC6335 talks about the issue in trying to recover such entries.
>> >
>> > In general, it recommends that even if they are recovered, at best 
>> they would be marked as “RESERVED” until other values have been assigned and 
>> the space requires reuse of those dead entries.
>> >
>> > So the net effect is:
>> > a) the list will never actually reflect what is deployed (as Bob notes 
>> below)
>> > b) garbage-collecting will at best mark some subset as dead
>> > c) but the available entries won’t be reused until we run out anyway
>> >
>> > Given the number of remaining entries, the task of garbage collection 
>> seems of little value.
>>
>> Until the day when it seems urgent...
>>
>>     Brian
>>
>> >
>> > Joe
>> >
>> >> On Sep 20, 2019, at 1:31 PM, Bob Hinden > <mailto:bob.hin...@gmail.com>> wrote:
>> >>
>> >> Andy,
>> >>
>> >>> On Sep 20, 2019, at 10:37 AM, Andrew G. Malis > <mailto:agma...@gmail.com>> wrote:
>> >>>
>> >>> Behcet,
>> >>>
>> >>> That was a historical list. The current assignments are in 
>> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml . 
>> If you want to go garbage collecting, that's the place to start.
>> >>
>> >> It's difficult to tell which are no longer used.  For example, I was 
>> recently asked about the Reliable Data Protocol, it’s IANA assignment:
>> >>
>> >> 27   RDP     Reliable Data Protocol          [RFC908][Bob_Hinden]
>> >>
>> >> I assumed it was no longer used.   Later by happenstance, I learned 
>> it is specified by ETSI as mandatory to implement in eSIMs.  I had no idea.
>> >>
>> >> Bob
>> >>
>> >>
>> >> ___
>> >> internet-history mailing list
>> >> internet-hist...@mailman.postel.org 
>> <mailto:internet-hist...@mailman.postel.org>
>> >> http://mailman.postel.org/mailman/listinfo/internet-history
>> >> Contact list-ow...@mailman.postel.org 
>> <mailto:list-ow...@mailman.postel.org> for assistance.
>> >
>> > ___
>> > internet-history mailing list
>> > internet-hist...@mailman.postel.org 
>> <mailto:internet-hist...@mailman.postel.org>
>> > http://mailman.postel.org/mailman/listinfo/internet-history
>> > Contact list-ow...@mailman.postel.org 
>> <mailto:list-ow...@mailman.postel.org> for assistance.
>> >
>>
>> ___
>> Int-area mailing list
>> Int-area@ietf.org <mailto:Int-area@ietf.org>
>> https://www.ietf.org/mailman/listinfo/int-area
>>
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [ih] Fwd: Existing use of IP protocol 114 (any 0-hop protocol)

[Brian E Carpenter]

On 21-Sep-19 14:11, Joe Touch wrote:
> FWIW, there are many registries with such “dead” entries.

114 is a bit special. By definition, all our normal traffic monitoring 
techniques will *never* see protocol 114 unless by chance they are installed on 
a layer 2 segment where it is in use. So even if no traces anywhere include it 
for ten years, we still can't assert that it is out of use. It seems harder to 
prove than most negatives :-).
 
> RFC6335 talks about the issue in trying to recover such entries.
> 
> In general, it recommends that even if they are recovered, at best they would 
> be marked as “RESERVED” until other values have been assigned and the space 
> requires reuse of those dead entries.
> 
> So the net effect is:
> a) the list will never actually reflect what is deployed (as Bob notes below)
> b) garbage-collecting will at best mark some subset as dead
> c) but the available entries won’t be reused until we run out anyway
> 
> Given the number of remaining entries, the task of garbage collection seems 
> of little value.

Until the day when it seems urgent...

Brian

> 
> Joe
> 
>> On Sep 20, 2019, at 1:31 PM, Bob Hinden  wrote:
>>
>> Andy,
>>
>>> On Sep 20, 2019, at 10:37 AM, Andrew G. Malis  wrote:
>>>
>>> Behcet,
>>>
>>> That was a historical list. The current assignments are in 
>>> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml . 
>>> If you want to go garbage collecting, that's the place to start.
>>
>> It's difficult to tell which are no longer used.  For example, I was 
>> recently asked about the Reliable Data Protocol, it’s IANA assignment:
>>
>> 27   RDP Reliable Data Protocol  [RFC908][Bob_Hinden]
>>
>> I assumed it was no longer used.   Later by happenstance, I learned it is 
>> specified by ETSI as mandatory to implement in eSIMs.  I had no idea.
>>
>> Bob
>>
>>
>> ___
>> internet-history mailing list
>> internet-hist...@mailman.postel.org
>> http://mailman.postel.org/mailman/listinfo/internet-history
>> Contact list-ow...@mailman.postel.org for assistance.
> 
> ___
> internet-history mailing list
> internet-hist...@mailman.postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-ow...@mailman.postel.org for assistance.
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

[Brian E Carpenter]

On 12-Sep-19 10:59, Bob Hinden wrote:
> Fred,
> 
>> On Sep 11, 2019, at 7:48 AM, Templin (US), Fred L 
>>  wrote:
>>
>> Geoff, the 1280 MTU came from Steve Deering's November 13, 1997 proposal to
>> the ipngwg. The exact message from the ipng archives is reproduced below.
>>
>> 1280 isn't just a recommendation - it's *the law*. Any link that cannot do 
>> 1280
>> (tunnels included) is not an IPv6 link.
> 
> Yes from IPv6’s view, but you can make a link that can’t do 1280 work if it 
> has its own local L2 fragmentation / reassembly as noted in Steve’s email.  
> ATM with is 53 byte cells comes to mind.

IPv4 with a small PMTU also comes to mind, as discussed in Section 3.2.2 of RFC 
4213:

   In this case, the IPv6 layer has to "see" a link
   layer with an MTU of 1280 bytes and the encapsulator has to use IPv4
   fragmentation in order to forward the 1280 byte IPv6 packets.

  Brian

> 
> Bob
> 
> 
>>
>> Fred
>>
>> ---
>> From owner-i...@sunroof.eng.sun.com  Thu Nov 13 16:41:01 1997
>> Received: (from majordomo@localhost)
>>  by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA14339
>>  for ipng-dist; Thu, 13 Nov 1997 16:38:00 -0800 (PST)
>> Received: from Eng.Sun.COM (engmail1 [129.146.1.13])
>>  by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA14332
>>  for ; Thu, 13 Nov 1997 16:37:51 -0800 (PST)
>> Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
>>  by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA28654
>>  for ; Thu, 13 Nov 1997 16:37:48 -0800
>> Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88])
>>  by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA28706
>>  for ; Thu, 13 Nov 1997 16:37:49 -0800 (PST)
>> Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by 
>> postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA20862; Thu, 13 
>> Nov 1997 16:37:48 -0800 (PST)
>> X-Sender: deer...@postoffice.cisco.com
>> Message-Id: 
>> Mime-Version: 1.0
>> Content-Type: text/plain; charset="us-ascii"
>> Date: Thu, 13 Nov 1997 16:37:00 -0800
>> To: IPng Working Group 
>> From: Steve Deering 
>> Subject: (IPng 4802) increasing the IPv6 minimum MTU
>> Cc: hin...@ipsilon.com
>> Sender: owner-i...@eng.sun.com
>> Precedence: bulk
>>
>> In the ipngwg meeting in Munich, I proposed increasing the IPv6 minimum MTU
>> from 576 bytes to something closer to the Ethernet MTU of 1500 bytes, (i.e.,
>> 1500 minus room for a couple layers of encapsulating headers, so that min-
>> MTU-size packets that are tunneled across 1500-byte-MTU paths won't be
>> subject to fragmentation/reassembly on ingress/egress from the tunnels,
>> in most cases).
>>
>> After the short discussion in the Munich meeting, I called for a show of
>> hands, and of those who raised their hands (about half the attendees, if
>> I recall correctly), the vast majority were in favor of this change --
>> there were only two or three people opposed.  However, we recognized that
>> a fundamental change of this nature requires thoughtful discussion and
>> analysis on the mailing list, to allow those who were not at the meeting
>> and those who were there but who have since had second thoughts, to express
>> their opinions.  A couple of people have already, in private conversation,
>> raised some concerns that were not identified in the discussion at the
>> meeting, which I report below.  We would like to get this issue settled as
>> soon as possible, since this is the only thing holding up the publication
>> of the updated Proposed Standard IPv6 spec (the version we expect to advance
>> to Draft Standard), so let's see if we can come to a decision before the ID
>> deadline at the end of next week (hoping there isn't any conflict between
>> "thoughtful analysis" and "let's decide quickly" :-).
>>
>> The reason I would like to increase the minimum MTU is that there are some
>> applications for which Path MTU Discovery just won't work very well, and
>> which will therefore limit themselves to sending packets no larger than
>> the minimum MTU.  Increasing the minimum MTU would improve the bandwidth
>> efficiency, i.e., reduce the header overhead (ratio of header bytes to
>> payload bytes), for those applications.  Some examples of such applications
>> are:
>>
>>(1) Large-fanout, high-volume multicast apps, such as multicast video
>>  ("Internet TV"), multicast netnews, and multicast software
>>  distribution.  I believe these applications will end up limiting
>>  themselves to packets no large than the min MTU in order to avoid
>>  the danger of incurring  an "implosion" of ICMP Packet-Too-Big
>>  messages in response.  Even though we have specified that router
>>  implementations must carefully rate-limit the emission of ICMP
>>  error messages, I am nervous about how well this will work in
>>  practice, especially once there is a lot of high-speed, bulk
>>  multicasting happening.  An appropriate choice of rate 

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

[Brian E Carpenter]

On 09-Sep-19 16:11, Joe Touch wrote:
> 
> 
>> On Sep 8, 2019, at 8:50 PM, Brian E Carpenter > <mailto:brian.e.carpen...@gmail.com>> wrote:
>>
>> On 09-Sep-19 12:15, Joe Touch wrote:
>>>
>>>
>>>> On Sep 8, 2019, at 1:26 PM, Brian E Carpenter >>> <mailto:brian.e.carpen...@gmail.com> <mailto:brian.e.carpen...@gmail.com>> 
>>>> wrote:
>>>>
>>>>>>
>>>>>> Wouldn't that require the middle box to become an architectural element?
>>>>>
>>>>> Yes, but not just “an” (one):
>>>>>
>>>>> Touch, J: Middlebox Models Compatible with the Internet. USC/ISI 
>>>>> (ISI-TR-711), 2016. (Type: Technical Report | Links | BibTeX)
>>>>>
>>>>>  * https://www.strayalpha.com/pubs/isi-tr-711.pdf
>>>>
>>>> I'll take the liberty of pointing out that we've known for many years that
>>>> there are multiple types of middleboxes and they have multiple facets:
>>>> https://tools.ietf.org/html/rfc3234
>>>
>>> Facets are just properties. That doc makes no attempt to describe them as 
>>> architectural roles.
>>
>> Agreed. My point is that the issue has been lying on the IETF table for many 
>> years, and we've collectively chosen to ignore it.
> 
> By “we”, I’m not sure who you mean. There have been plenty of us complaining 
> about this gap for a very long time in the IETF.

Yes, but the IAB hasn't really taken up the issue and we haven't ever had a WG 
that seriously tackled it, IMHO.

> 
>>
>>>>
>>>> So far, we haven't added them to any formal architectural description of
>>>> the Internet, probably because we don't have one.
>>>
>>> RFC1122, RFC1123, RFC1812 as standards.
>>>
>>> I (and IMO those RFCs) disagree with the position you took in RFC1958, FWIW.
>>
>> "you" = the IAB in 1996; I was only the document editor.
> 
> Fair point, but presumably you were on the IAB at the time?

Yes indeed. But although it's almost my most-cited RFC, I don't deserve sole 
credit or sole blame.

> 
>> But IMHO those RFCs are not architectural as such. They describe functions 
>> of nodes, not how the nodes work together as a system.
> 
> An architecture is (IMO) the behavior of a system that is the consequence of 
> the behavior of its components and the ways in which they interact.
> 
> Arguably, those RFCs - adding 791 and 3819, and a few others, do exactly 
> that. In a nutshell: routers relay; subnets (as links) interconnect), and 
> hosts source, sink, and do the rest (including reliability), all based on 
> globally-unique addresses in that can be aggregated by bit prefix. No, 
> there’s no “roadmap” doc that provides the top-level description, but the 
> rest is definitely there in those and other docs.

Yes, we agree about that. It's the roadmap that is missing.

> IMO, the issue is that middleboxes can’t simply be added to that list 
> consistently - they aren’t a third thing that can be peers to routers or 
> hosts. There is a way to describe them that’s consistent, though - but only 
> if they are different elements when viewed from different points in the 
> network (as I described in the tech report).

I can't disagree.

   Brian
> 
> Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

[Brian E Carpenter]

On 09-Sep-19 12:15, Joe Touch wrote:
> 
> 
>> On Sep 8, 2019, at 1:26 PM, Brian E Carpenter > <mailto:brian.e.carpen...@gmail.com>> wrote:
>>
>>>>
>>>> Wouldn't that require the middle box to become an architectural element?
>>>
>>> Yes, but not just “an” (one):
>>>
>>> Touch, J: Middlebox Models Compatible with the Internet. USC/ISI 
>>> (ISI-TR-711), 2016. (Type: Technical Report | Links | BibTeX)
>>>
>>>  * https://www.strayalpha.com/pubs/isi-tr-711.pdf
>>
>> I'll take the liberty of pointing out that we've known for many years that
>> there are multiple types of middleboxes and they have multiple facets:
>> https://tools.ietf.org/html/rfc3234
> 
> Facets are just properties. That doc makes no attempt to describe them as 
> architectural roles.

Agreed. My point is that the issue has been lying on the IETF table for many 
years, and we've collectively chosen to ignore it.
 
>>
>> So far, we haven't added them to any formal architectural description of
>> the Internet, probably because we don't have one.
> 
> RFC1122, RFC1123, RFC1812 as standards.
> 
> I (and IMO those RFCs) disagree with the position you took in RFC1958, FWIW.

"you" = the IAB in 1996; I was only the document editor. But IMHO those RFCs 
are not architectural as such. They describe functions of nodes, not how the 
nodes work together as a system.

Brian

> 
> Joe
> 
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

[Brian E Carpenter]

On 09-Sep-19 06:06, Joe Touch wrote:
> 
> 
>> On Sep 8, 2019, at 6:16 AM, Fred Baker > > wrote:
>>
>>
>>
>>> On Sep 5, 2019, at 5:31 PM, Tom Herbert >> > wrote:
>>>
>>> I really wish the IAB would look at the issues of wide
>>> spread middlebox non-conformance
>>
>> Wouldn't that require the middle box to become an architectural element?
> 
> Yes, but not just “an” (one):
> 
> Touch, J: Middlebox Models Compatible with the Internet. USC/ISI 
> (ISI-TR-711), 2016. (Type: Technical Report | Links | BibTeX)
> 
>   * https://www.strayalpha.com/pubs/isi-tr-711.pdf

I'll take the liberty of pointing out that we've known for many years that
there are multiple types of middleboxes and they have multiple facets:
https://tools.ietf.org/html/rfc3234

So far, we haven't added them to any formal architectural description of
the Internet, probably because we don't have one.

Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

[Brian E Carpenter]

On 07-Aug-19 13:06, Joel M. Halpern wrote:
> Brian, I would think the text just above the paragraph Alissa quoted 
> would already cover what you ask for.  It begins:
>  Developers SHOULD NOT develop new protocols or applications that
>  rely on IP fragmentation.

Well yes, so the "unless" clause would fit right there. Saying both "SHOULD 
NOT" and "MAY" is redundant, which is why the word "unless" exists. So 
basically this is editorial (since Fernando is correct about the WG intention).

Although switching to "unless" doesn't exactly resolve Alissa's issue, I think 
it makes it clear that relying on fragmentation is a risky choice, whereas the 
MAY formulation makes it seem almost OK.

   Brian

> 
> Yours,
> Joel
> 
> On 8/6/2019 8:55 PM, Brian E Carpenter wrote:
>> On 07-Aug-19 12:11, Alissa Cooper wrote:
>>> Hi Tom,
>>>
>>>> On Aug 6, 2019, at 5:41 PM, Tom Herbert  wrote:
>>>>
>>>> On Tue, Aug 6, 2019 at 1:30 PM Alissa Cooper via Datatracker
>>>>  wrote:
>>>>>
>>>>> Alissa Cooper has entered the following ballot position for
>>>>> draft-ietf-intarea-frag-fragile-15: Discuss
>>>>>
>>>>> When responding, please keep the subject line intact and reply to all
>>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>>> introductory paragraph, however.)
>>>>>
>>>>>
>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>
>>>>>
>>>>> The document, along with other ballot positions, can be found here:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> DISCUSS:
>>>>> --
>>>>>
>>>>> Thanks for writing this document.
>>>>>
>>>>> Section 6.1 says:
>>>>>
>>>>> "Developers MAY develop new protocols or applications that rely on IP
>>>>>fragmentation if the protocol or application is to be run only in
>>>>>environments where IP fragmentation is known to be supported."
>>>>>
>>>>> I'm wondering if there should be a bit more nuance here to make the
>>>>> recommendation clearer. Do we think there is a case where an application
>>>>> protocol developed in the IETF will be known to only run in environments 
>>>>> where
>>>>> fragmentation is supported? If we don't think developing such a protocol 
>>>>> would
>>>>> be in scope for the IETF, then I'm wondering if that case should be 
>>>>> called out
>>>>> explicitly with a stronger normative requirement.
>>>>>
>>>> Alissa,
>>>>
>>>> Are you distinguishing between protocol development and application
>>>> development?
>>>
>>> I’m specifically wondering about application protocols (as distinct from 
>>> other protocols) developed in the IETF (as distinct from developed 
>>> elsewhere). Sometimes we use BCPs to guide future work in the IETF 
>>> specifically, and it seemed to me that in that specific slice — 
>>> IETF-developed application protocols — we may be able to make a stronger 
>>> recommendation since we can’t be sure of the environment in which any given 
>>> application protocol would be deployed (I think, but would be open to 
>>> arguments otherwise).
>>
>> fwiw, I agree with what I think Alissa is saying. Unless we actually 
>> *implement* a mechanism to define and support limited domains 
>> (draft-carpenter-limited-domains) protocol designers cannot safely make 
>> assumptions such as "fragmentation works".
>>
>> Maybe this paragraph needs to be more of a health warning than a somewhat 
>> dubious RFC2119 statement. At least, "should not ... unless" might be a 
>> better formulation than "MAY ... if".
>>
>> Brian
>>
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
>>
> .
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

[Brian E Carpenter]

On 07-Aug-19 12:11, Alissa Cooper wrote:
> Hi Tom,
> 
>> On Aug 6, 2019, at 5:41 PM, Tom Herbert  wrote:
>>
>> On Tue, Aug 6, 2019 at 1:30 PM Alissa Cooper via Datatracker
>>  wrote:
>>>
>>> Alissa Cooper has entered the following ballot position for
>>> draft-ietf-intarea-frag-fragile-15: Discuss
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
>>>
>>>
>>>
>>> --
>>> DISCUSS:
>>> --
>>>
>>> Thanks for writing this document.
>>>
>>> Section 6.1 says:
>>>
>>> "Developers MAY develop new protocols or applications that rely on IP
>>>   fragmentation if the protocol or application is to be run only in
>>>   environments where IP fragmentation is known to be supported."
>>>
>>> I'm wondering if there should be a bit more nuance here to make the
>>> recommendation clearer. Do we think there is a case where an application
>>> protocol developed in the IETF will be known to only run in environments 
>>> where
>>> fragmentation is supported? If we don't think developing such a protocol 
>>> would
>>> be in scope for the IETF, then I'm wondering if that case should be called 
>>> out
>>> explicitly with a stronger normative requirement.
>>>
>> Alissa,
>>
>> Are you distinguishing between protocol development and application
>> development?
> 
> I’m specifically wondering about application protocols (as distinct from 
> other protocols) developed in the IETF (as distinct from developed 
> elsewhere). Sometimes we use BCPs to guide future work in the IETF 
> specifically, and it seemed to me that in that specific slice — 
> IETF-developed application protocols — we may be able to make a stronger 
> recommendation since we can’t be sure of the environment in which any given 
> application protocol would be deployed (I think, but would be open to 
> arguments otherwise).

fwiw, I agree with what I think Alissa is saying. Unless we actually 
*implement* a mechanism to define and support limited domains 
(draft-carpenter-limited-domains) protocol designers cannot safely make 
assumptions such as "fragmentation works".

Maybe this paragraph needs to be more of a health warning than a somewhat 
dubious RFC2119 statement. At least, "should not ... unless" might be a better 
formulation than "MAY ... if".

   Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] Fwd: ID Tracker Stream Change Notice:

[Brian E Carpenter]

Hi,

Since the Limited Domains draft has been discussed on this list, this is to let 
you know that we've now submitted it for publication as an Independent 
Submission RFC.

Feedback is of course still very welcome.

Regards
 Brian & Bing


 Forwarded Message 
Subject: ID Tracker Stream Change Notice: 

Resent-Date: Fri, 19 Jul 2019 14:12:09 -0700 (PDT)
Resent-From: alias-boun...@ietf.org
Resent-To: brian.e.carpen...@gmail.com, leo.liub...@huawei.com
Date: Fri, 19 Jul 2019 14:12:09 -0700
From: IETF Secretariat 
To: draft-carpenter-limited-doma...@ietf.org, rfc-...@rfc-editor.org

Stream changed to ISE from None
Datatracker URL: 
https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-08.txt

[Brian E Carpenter]

Hi,

We've updated this draft according to comments received. At the moment
the authors plan to submit it to the Independent Submissions RFC stream.
If anybody thinks it should be an IETF stream document, please let
us know.

Regards
Brian & Bing


 Forwarded Message 
Subject: I-D Action: draft-carpenter-limited-domains-08.txt
Date: Tue, 11 Jun 2019 13:32:33 -0700
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Limited Domains and Internet Protocols
Authors : Brian Carpenter
  Bing Liu
Filename: draft-carpenter-limited-domains-08.txt
Pages   : 27
Date: 2019-06-11

Abstract:
   There is a noticeable trend towards network requirements, behaviours
   and semantics that are specific to a limited region of the Internet
   and a particular set of requirements.  Policies, default parameters,
   the options supported, the style of network management and security
   requirements may vary.  This document reviews examples of such
   limited domains, also known as controlled environments, and emerging
   solutions, and includes a related taxonomy.  It then briefly
   discusses the standardization of protocols for limited domains.
   Finally, it shows the needs for a precise definition of limited
   domain membership and for mechanisms to allow nodes to join a domain
   securely and to find other members, including boundary nodes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-limited-domains-08
https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-herbert-ipv4-udpencap-eh-00.txt

[Brian E Carpenter]

On 06-Mar-19 05:42, Tom Herbert wrote:
> Hi Brian,
> 
> On Mon, Mar 4, 2019 at 5:37 PM Brian E Carpenter
>  wrote:
>>
>> Hi,
>>
> Hi Brian,
> 
> Thanks for the comments!
> 
>> This is an interesting draft, but I must say I have serious doubts about
>> the IETF working on any significant update to IPv4 at the IP header level,
>> or of any such updates ever making it into the operational network.
>>
> 
> I understand the concern. It's probably true that extension headers in
> IPv4 wouldn't be very usable in today's Internet. Undoubtedly, many
> middleboxes would block them. But that's not because middleboxes are
> concerned about a threat of extension headers in IPv4, it's more
> because some middleboxes drop packets with any protocols they don't
> understand (pretty much leaving only TCP and UDP as being usable
> protocols on the Internet). There are some potential mitigations to be
> pointed out:
> 
> - IPv4 already supports at least two extension headers, namely ESP and
> AH. They might not be called extension headers, but they have the same
> format and function as IPv6 cognates.
> - There's no concept of HBH options in IPv4 as needing to be processed
> by every node in the path, so the relaxed processing requirement of
> RFC8200 can be set from the start without legacy issues.
> - This doesn't actually change IP header, it is just enabling new
> values in the protocol field. In a host implementation this is very
> straightforward and in some ways it's a simplification to to be more
> like IPv6.
> - UDP encapsulation of extension headers could serve to make extension
> headers transparent to middleboxes.
> - It is conceivable to only allow extension headers in UDP
> encapsulation thereby eliminating the problem of making a core update
> to IPv4. IPv4 extension headers would be defined as part of an
> encapsulation protocol.
> - IPv4 extension headers could be another use case for limited domains.
> 
>> On the other hand, I think the idea of a UDP encapsulation of extension
>> headers is very interesting. I'm not sure I understand all the implications
>> yet, and I'm not sure why the format can't be defined simply by a normative
>> reference to RFC8200. The idea of having a duplicate format definition
>> is a bit scary.
> 
> Some implications are described in the document. When encapsulating
> transport packets within UDP the IP header for the encapsulated
> transport header needs to be deterministic, how to deal with NAT and
> encapsulated transport checksum needs a solution. Intermediate nodes
> parsing HBH embedded options is tricky since that requires them to
> inspect UDP payloads and potential modify the payload. For that, a
> magic number is used to minimize the possibility of misinterpretation
> of UDP payload type. If you think of other implications please bring
> them up.
> 
> I'm not sure what the comment on duplicate format definition refers
> to. Perhaps this is about the the description of extension headers for
> IPv4 in the draft?

Yes. I'd rather see them defined as IPv6 extension headers patched for
IPv4, with no duplication of other parts of the definitions. Otherwise
there'll be a risk of them drifting apart.

   Brian
> 
> Thanks,
> Tom
> 
> 
> 
> 
>>
>> Regards
>>Brian Carpenter
>>
>> On 28-Feb-19 09:19, internet-dra...@ietf.org wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>>
>>>
>>> Title   : IPv4 Extension Headers and UDP Encapsulated 
>>> Extension Headers
>>> Author  : Tom Herbert
>>>   Filename: draft-herbert-ipv4-udpencap-eh-00.txt
>>>   Pages   : 27
>>>   Date: 2019-02-27
>>>
>>> Abstract:
>>>This specification defines extension headers for IPv4 and a method to
>>>encapsulate extension headers in UDP to facilitate transmission over
>>>the Internet. The goal is to provide a uniform and feasible method of
>>>extensibility that is shared between IPv4 and IPv6.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-herbert-ipv4-udpencap-eh/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-herbert-ipv4-udpencap-eh-00
>>> https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-udpencap-eh-00
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized v

Re: [Int-area] I-D Action: draft-herbert-ipv4-udpencap-eh-00.txt

[Brian E Carpenter]

On 06-Mar-19 04:55, Tom Herbert wrote:
> On Tue, Mar 5, 2019 at 2:30 AM Stewart Bryant  
> wrote:
>>
>>
>> On 05/03/2019 01:37, Brian E Carpenter wrote:
>>> Hi,
>>>
>>> This is an interesting draft, but I must say I have serious doubts about
>>> the IETF working on any significant update to IPv4 at the IP header level,
>>> or of any such updates ever making it into the operational network.
>>
>> This is something that worries me, in that the IETF seems to be
>> deserting the IPv4 market sector before it is clear that the market is
>> fully committed to an IPv6 only world.
>>
> Stewart,
> 
> I agree. It's clear that IPv4 isn't going away any time soon (e.g.
> https://www.internetgovernance.org/2019/01/04/is-there-hope-for-ipv6/).
> Bringing beneficial features into IPv4 from Ipv6, like the
> aforemention extension headers, could promote uniformity between the
> versions and might help to facilitate transition to IPv6.

Well, I worded my comment quite carefully. IPv4 will fade out over many
years, and any attempt to actively kill it would backfire. But that
doesn't mean that the intensively conservative enterprise network
operators will rush to enable new features. Rather the opposite, in
fact. That's why I give the UDP encapsulation approach a much better
chance of success, whether the carrier is IPv6 or IPv4.

   Brian

> 
> Tom
> 
>> Certainly a lot of enterprise networks and SP cores are still IPv4 only
>> with no apparent intention to shift in the near future.
>>
>> Markets and standards, like nature, abhor a vacuum, and if we do not
>> continue to serve the IPv4 needs some other (quasi) SDO will appear in
>> support of users with requirements and vendors that never leave money on
>> the table.
>>
>> - Stewart
>>
>>
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-herbert-ipv4-udpencap-eh-00.txt

[Brian E Carpenter]

Hi,

This is an interesting draft, but I must say I have serious doubts about
the IETF working on any significant update to IPv4 at the IP header level,
or of any such updates ever making it into the operational network.

On the other hand, I think the idea of a UDP encapsulation of extension
headers is very interesting. I'm not sure I understand all the implications
yet, and I'm not sure why the format can't be defined simply by a normative
reference to RFC8200. The idea of having a duplicate format definition
is a bit scary.

Regards
   Brian Carpenter

On 28-Feb-19 09:19, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> Title   : IPv4 Extension Headers and UDP Encapsulated 
> Extension Headers
> Author  : Tom Herbert
>   Filename: draft-herbert-ipv4-udpencap-eh-00.txt
>   Pages   : 27
>   Date: 2019-02-27
> 
> Abstract:
>This specification defines extension headers for IPv4 and a method to
>encapsulate extension headers in UDP to facilitate transmission over
>the Internet. The goal is to provide a uniform and feasible method of
>extensibility that is shared between IPv4 and IPv6.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-herbert-ipv4-udpencap-eh/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-herbert-ipv4-udpencap-eh-00
> https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-udpencap-eh-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-06.txt

[Brian E Carpenter]

On 03-Mar-19 09:35, Tom Herbert wrote:
> On Sat, Mar 2, 2019 at 11:50 AM Brian E Carpenter
>  wrote:
>>
>> On 03-Mar-19 06:35, Tom Herbert wrote:
>>> On Fri, Mar 1, 2019 at 7:18 PM Brian E Carpenter
>>>  wrote:
>>>>
>>>> On 02-Mar-19 14:46, Tom Herbert wrote:
>>>>> Hi Brain,
>>>>>
>>>>> One comment...
>>>>>
>>>>> >From the draft:
>>>>>
>>>>> "5.   Firewall and Service Tickets (FAST).  Such tickets would
>>>>> accompany a packet to claim the right to traverse a network or request
>>>>> a specific network service [I-D.herbert-fast].  They would only be
>>>>> valid within a particular domain."
>>>>>
>>>>> While it's true that Firewall and Service and Tickets (in HBH
>>>>> extension headers) are only valid in a particular domain, that really
>>>>> means that they are only interpretable in the origin domain that
>>>>> created the ticket. It's essential in the design that FAST tickets can
>>>>> be exposed outside of their origin domain (e.g. used over the
>>>>> Internet) and reflected back into the origin domain by peer hosts.
>>>>> FAST tickets contain their own security (they are encrypted and signed
>>>>> by agent in the origin network) so there should never be any reason
>>>>> for a firewall to arbitrarily filter or limit packets with FAST
>>>>> tickets attached. This technique could probably be applied to some of
>>>>> the other use cases mentioned.
>>>>
>>>> Yes, that's an interesting model: effectively a domain split into various
>>>> parts without needing a traditional VPN.
>>>>
>>>> Of course, there remains the bogeyman of making the Internet transparent
>>>> to some new unknown option or extension header. I'm pessimistic about that.
>>>> So far we have had poor success.
>>>
>>> Maybe, although I wouldn't phrase it exactly that way. Protocol
>>> ossification of the Internet and the abandonment of the End-to-End
>>> model has made evolution of the Internet harder, but I don't believe
>>> it is yet proven impossible. This goes back to my primary concern that
>>> if the concept of limited domains is standardized, some people will
>>> use it as rationalization to justify non-conformant implementation and
>>> proprietary, non-interoperable solutions as somehow being compatible
>>> with Internet architecture and ideals.
>>
>> I certainly acknowledge that risk; but (having lived with this problem
>> in some form or other since RFC2101) I really think we can't duck it any
>> longer.
>>
>> Also, we really have standardized limited domains already, in numerous
>> places - segment routing and detnet being recent examples. I think
>> ultimately what we're arguing in the draft is: let's do it properly.
> 
> Hi Brian,
> 
> Yes, limited domains in the form of administrative domains and
> security domains have existed for quite some time (since NAT, RFC1918,
> firewalls first came into being). Every service provider and
> datacenter operator have implemented a domain. But those distinguished
> domains by the operation and use of the protocol, not in the
> definition of a protocol or its interoperability which seems to be
> proposed in the draft..
> 
> The draft states:
> 
> "This documents analyses and discusses some of the consequences of
> this trend, and how it impacts the idea of universal interoperability
> in the Internet"
> 
> I don't see much discussion in the draft on the impact of
> interoperability. This is critical. Interoperability is a core
> principle in the Internet. If, for instance, a protocol is specified
> to only work and be interoperable in a limited domain then would it
> still be called an Internet protocol? (to me, it seems like an
> oxymoron to call something an Internet protocol that doesn't even work
> on the Internet). It would good for the draft to elaborate on this.

I think we already distinguish between a protocol that runs over the
open Internet and a local protocol that runs over IP, with a limited
scope for interoperability. And we distinguish between a standardised
protocol and a private (possibly undocumented) protocol. What we're
arguing is that "standardised and interoperable" can be a very useful
property of a local protocol, and such a protocol can be very useful
even though it's *not* designed to run across the open Internet.

We'll try to make this argument clearer in the next ver

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-06.txt

[Brian E Carpenter]

On 03-Mar-19 06:35, Tom Herbert wrote:
> On Fri, Mar 1, 2019 at 7:18 PM Brian E Carpenter
>  wrote:
>>
>> On 02-Mar-19 14:46, Tom Herbert wrote:
>>> Hi Brain,
>>>
>>> One comment...
>>>
>>> >From the draft:
>>>
>>> "5.   Firewall and Service Tickets (FAST).  Such tickets would
>>> accompany a packet to claim the right to traverse a network or request
>>> a specific network service [I-D.herbert-fast].  They would only be
>>> valid within a particular domain."
>>>
>>> While it's true that Firewall and Service and Tickets (in HBH
>>> extension headers) are only valid in a particular domain, that really
>>> means that they are only interpretable in the origin domain that
>>> created the ticket. It's essential in the design that FAST tickets can
>>> be exposed outside of their origin domain (e.g. used over the
>>> Internet) and reflected back into the origin domain by peer hosts.
>>> FAST tickets contain their own security (they are encrypted and signed
>>> by agent in the origin network) so there should never be any reason
>>> for a firewall to arbitrarily filter or limit packets with FAST
>>> tickets attached. This technique could probably be applied to some of
>>> the other use cases mentioned.
>>
>> Yes, that's an interesting model: effectively a domain split into various
>> parts without needing a traditional VPN.
>>
>> Of course, there remains the bogeyman of making the Internet transparent
>> to some new unknown option or extension header. I'm pessimistic about that.
>> So far we have had poor success.
> 
> Maybe, although I wouldn't phrase it exactly that way. Protocol
> ossification of the Internet and the abandonment of the End-to-End
> model has made evolution of the Internet harder, but I don't believe
> it is yet proven impossible. This goes back to my primary concern that
> if the concept of limited domains is standardized, some people will
> use it as rationalization to justify non-conformant implementation and
> proprietary, non-interoperable solutions as somehow being compatible
> with Internet architecture and ideals.

I certainly acknowledge that risk; but (having lived with this problem
in some form or other since RFC2101) I really think we can't duck it any
longer.

Also, we really have standardized limited domains already, in numerous
places - segment routing and detnet being recent examples. I think
ultimately what we're arguing in the draft is: let's do it properly.

Brian

Brian


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-06.txt

[Brian E Carpenter]

On 02-Mar-19 14:46, Tom Herbert wrote:
> Hi Brain,
> 
> One comment...
> 
>>From the draft:
> 
> "5.   Firewall and Service Tickets (FAST).  Such tickets would
> accompany a packet to claim the right to traverse a network or request
> a specific network service [I-D.herbert-fast].  They would only be
> valid within a particular domain."
> 
> While it's true that Firewall and Service and Tickets (in HBH
> extension headers) are only valid in a particular domain, that really
> means that they are only interpretable in the origin domain that
> created the ticket. It's essential in the design that FAST tickets can
> be exposed outside of their origin domain (e.g. used over the
> Internet) and reflected back into the origin domain by peer hosts.
> FAST tickets contain their own security (they are encrypted and signed
> by agent in the origin network) so there should never be any reason
> for a firewall to arbitrarily filter or limit packets with FAST
> tickets attached. This technique could probably be applied to some of
> the other use cases mentioned.

Yes, that's an interesting model: effectively a domain split into various
parts without needing a traditional VPN.

Of course, there remains the bogeyman of making the Internet transparent
to some new unknown option or extension header. I'm pessimistic about that.
So far we have had poor success.

Brian

> 
> Thanks,
> Tom
> 
> On Fri, Mar 1, 2019 at 5:08 PM Brian E Carpenter
>  wrote:
>>
>> A few small updates and fixes to references. Please comment;
>> the authors are wondering about next steps for this draft.
>>
>> Brian + Bing
>>
>>  Forwarded Message 
>> Subject: I-D Action: draft-carpenter-limited-domains-06.txt
>> Date: Fri, 01 Mar 2019 17:04:37 -0800
>> From: internet-dra...@ietf.org
>> Reply-To: internet-dra...@ietf.org
>> To: i-d-annou...@ietf.org
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>
>>
>> Title   : Limited Domains and Internet Protocols
>> Authors : Brian Carpenter
>>   Bing Liu
>> Filename: draft-carpenter-limited-domains-06.txt
>> Pages   : 24
>> Date: 2019-03-01
>>
>> Abstract:
>>There is a noticeable trend towards network requirements, behaviours
>>and semantics that are specific to a limited region of the Internet
>>and a particular set of requirements.  Policies, default parameters,
>>the options supported, the style of network management and security
>>requirements may vary.  This document reviews examples of such
>>limited domains, also known as controlled environments, and emerging
>>solutions, and develops a related taxonomy.  It then briefly
>>discusses the standardization of protocols for limited domains.
>>Finally, it shows the needs for a precise definition of limited
>>domain membership and for mechanisms to allow nodes to join a domain
>>securely and to find other members, including boundary nodes.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-carpenter-limited-domains-06
>> https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-06
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-06
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> ___
>> I-D-Announce mailing list
>> i-d-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-06.txt

[Brian E Carpenter]

A few small updates and fixes to references. Please comment;
the authors are wondering about next steps for this draft.

Brian + Bing

 Forwarded Message 
Subject: I-D Action: draft-carpenter-limited-domains-06.txt
Date: Fri, 01 Mar 2019 17:04:37 -0800
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Limited Domains and Internet Protocols
Authors : Brian Carpenter
  Bing Liu
Filename: draft-carpenter-limited-domains-06.txt
Pages   : 24
Date: 2019-03-01

Abstract:
   There is a noticeable trend towards network requirements, behaviours
   and semantics that are specific to a limited region of the Internet
   and a particular set of requirements.  Policies, default parameters,
   the options supported, the style of network management and security
   requirements may vary.  This document reviews examples of such
   limited domains, also known as controlled environments, and emerging
   solutions, and develops a related taxonomy.  It then briefly
   discusses the standardization of protocols for limited domains.
   Finally, it shows the needs for a precise definition of limited
   domain membership and for mechanisms to allow nodes to join a domain
   securely and to find other members, including boundary nodes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-limited-domains-06
https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt

[Brian E Carpenter]

Thanks Ron. I think that's sufficient for this draft. You might consider adding 
citations of RFC6437 and RFC7098 as well
as 6438, to capture the whole picture.
 
Regards
   Brian

On 2019-01-31 09:36, Ron Bonica wrote:
> Inline...
> 
>>
>> Message: 2
>> Date: Wed, 30 Jan 2019 08:40:39 +1300
>> From: Brian E Carpenter 
>> To: int-area@ietf.org
>> Subject: Re: [Int-area] I-D Action:
>>  draft-ietf-intarea-frag-fragile-06.txt
>> Message-ID: <7bc33271-8cee-818a-036b-99d92d818...@gmail.com>
>> Content-Type: text/plain; charset=utf-8
>>
>> Reviewing this version, I noticed the absence of one mitigation that we 
>> should
>> probably be recommending.
>>
>> - in section 4.4. "Stateless Load Balancers" add the remark that balancers 
>> that
>> use *only* the IPv6 Source Address, IPv6 Destination Address and IPv6 Flow
>> Label (when it is non-zero) work perfectly on fragmented traffic.
>>
> 
> Fair enough. This is almost identical to a comment made by Tom Herbert. I 
> have added a few sentences to the end of Section 4.4 that address both.
> 
>> - in section 7. "Recommendations" add a subsection "To Load Balancer
>> Developers and Operators" saying that load balancers (including ECMP/LAG)
>> SHOULD be designed and configured to use *only* the IPv6 Source Address,
>> IPv6 Destination Address and IPv6 Flow Label (when it is non-zero).
>>
> 
> Also agree. Look for that section in Version 07
> 
>> Regards
>>Brian Carpenter
>>
>>
> ***
> .
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

[Brian E Carpenter]

On 2019-01-31 03:13, Stewart Bryant wrote:


>>> Add to section 7.3:
>>>
>>> "Routers SHOULD use IPv6 flow label for ECMP routing as described in 
>>> [RFC6438]."
> 
> If we want to migrate to the FL then we really need to state that the FL MUST 
> be set by the sender. Without, that we are never going to wean routers off 
> looking at the five tuple, if indeed we ever succeed in doing that.

I would have loved to make it a MUST in RFC6437 but that wasn't the consensus, 
so it's a SHOULD, confirmed this very day by RFC8504 
(https://tools.ietf.org/html/rfc8504#page-7).

As I said the other day, if and only if the flow label is non-zero, the 
{source, destination, flow_label} tuple is a fine thing for a load balancer to 
use. If the flow label is zero, you need to fall back to the 5-tuple, which is 
broken for fragmented packets as we know. So for IPv6 packets with a zero flow 
label and a fragmentation header, you have no choice but the {source, 
destination} tuple.

However, that is a much better picture than for IPv4.

Brian


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt

[Brian E Carpenter]

Reviewing this version, I noticed the absence of one mitigation that we should 
probably be recommending.

- in section 4.4. "Stateless Load Balancers" add the remark that balancers that 
use *only* the IPv6 Source Address, IPv6 Destination Address and IPv6 Flow 
Label (when it is non-zero) work perfectly on fragmented traffic.

- in section 7. "Recommendations" add a subsection "To Load Balancer Developers 
and Operators" saying that load balancers (including ECMP/LAG) SHOULD be 
designed and configured to use *only* the IPv6 Source Address, IPv6 Destination 
Address and IPv6 Flow Label (when it is non-zero).

Regards
   Brian Carpenter

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

[Brian E Carpenter]

On 2019-01-15 11:04, Tom Herbert wrote:
> Hello. I have a couple of comments:
> 
>>From the draft:
> "Middle boxes SHOULD process IP fragments in a manner that is
> compliant with RFC 791 and RFC 8200.  In many cases, middle boxes must
> maintain state in order to achieve this goal."
> 
> This requirement is confusing to me on several accounts. 

Me too. I think the root of the problem is the word "compliant". To
be compliant with the IP model, middleboxes should not exist. I think
what the text is trying to say is more like:

"Middle boxes SHOULD process IP fragments in a manner that is
consistent with RFC 791 and RFC 8200."

That's a requirement for effective transparency, not for compliance.

> First of all,
> there are a lot of requirements about fragmentation in both RFC791 and
> RFC8200, including some MUSTs. This requirement seems to be updating
> and possibly relaxing some of those requirements, but is not specific.
> This seems ambiguous as a normative requirement.
> 
> Secondly, the only specified interaction between fragmentation and
> intermediate nodes is that routers can fragment packets in IPv4. Other
> than that, a middlebox that complies with RFC791 and RFC8200 does not
> process or consider fragmentation of packets. Given that, it's unclear
> to me why middle boxes would need to maintain state to be protocol
> compliant. It's possible that the implicit exception of the
> requirement is that middleboxes might perform "in-network reassembly"
> or "virtual reassemlby" which would require state. If that is indeed
> the case then the requirements for the mechanisms should be spelled
> out.
> 
> For stateless load balancing (described in section 4.4), the IPv6 flow
> label obviates the need for DPI. It is sufficient to hash over the
> three tuple  to get good load balancing. All
> major OSes have been updated to set flow labels, and there are devices
> that already support this. IMO, the draft should make using flow label
> for stateless load balancing a SHOULD.

Agreed, and the text would need to be a bit reorganized for that, by
separating the v4 and v6 cases completely. Also things are rather
different for in-transit load balancing (including ECMP and LAG) and
server load balancing, but I don't think that changes the recommendation.
The draft could cite RFC7098 for the server case. In RFC7098, we
assumed that the balancer could revert to the old DPI method if the flow
label is zero, which may lead to a fail if the packet is fragmented.
But for in-transit load balancing of large numbers of flows, the
{source, dest, flow_label} tuple will provide entropy even if the
flow label is zero.

  Brian
 
> 
> Tom
> 
> On Mon, Jan 14, 2019 at 11:55 AM Joel M. Halpern  wrote:
>>
>> I have re-read this document.  I think it is a useful document that
>> captures that state of a complex tradeoff and makes effective
>> recommendations. I support publishing it as a BCP.
>>
>> If the authors make further additions, adding a mention of ECMP as a
>> particular case of stateless load balancers might further improve the
>> document.
>>
>> Yours,
>> Joel
>>
>> On 1/14/19 1:13 PM, Wassim Haddad wrote:
>>> Dear all,
>>>
>>> This email starts an Int-Area WG Last Call on the latest version of "IP 
>>> Fragmentation Considered Fragile” draft:
>>>
>>> https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-05
>>>
>>> Please respond to this email to support the document and/or send comments 
>>> by 2019-01-28.
>>>
>>> Please indicate if you are personally aware of any IPR that applies to 
>>> draft-ietf-intarea-frag-fragile-xx?
>>> If so, has this IPR been disclosed in compliance with IETF IPR rules?
>>>
>>>
>>> Regards,
>>>
>>> Juan & Wassim
>>> ___
>>> Int-area mailing list
>>> Int-area@ietf.org
>>> https://www.ietf.org/mailman/listinfo/int-area
>>>
>>
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-05.txt

[Brian E Carpenter]

An update following recent comments:

 Forwarded Message 
Subject: I-D Action: draft-carpenter-limited-domains-05.txt
Date: Wed, 12 Dec 2018 11:26:16 -0800
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Limited Domains and Internet Protocols
Authors : Brian Carpenter
  Bing Liu
Filename: draft-carpenter-limited-domains-05.txt
Pages   : 23
Date: 2018-12-12

Abstract:
   There is a noticeable trend towards network requirements, behaviours
   and semantics that are specific to a limited region of the Internet
   and a particular set of requirements.  Policies, default parameters,
   the options supported, the style of network management and security
   requirements may vary.  This document reviews examples of such
   limited domains, also known as controlled environments, and emerging
   solutions, and develops a related taxonomy.  It then briefly
   discusses the standardization of protocols for limited domains.
   Finally, it shows the needs for a precise definition of limited
   domain membership and for mechanisms to allow nodes to join a domain
   securely and to find other members, including boundary nodes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-limited-domains-05
https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-03.txt

[Brian E Carpenter]

Hi,

> 7.1.  For Application Developers
> 
>Protocol developers SHOULD NOT develop new protocols that rely on IP
>fragmentation.  However, they MAY develop new protocols that rely on
>IP fragmentation when no viable alternative exists.
> 
>Legacy protocols that depend upon IP fragmentation SHOULD be updated
>to break that dependency.  However, in some cases, there may be no
>viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
>in-IP encapsulation).  In these cases, the protocol will continue to
>rely on IP fragmentation

It occurs to me that another case where there is no viable alternative
is IPv6-to-IPv4 translation, if the translated IPv6 packet exceeds the
next hop IPv4 MTU. The last paragraph of section 5.1.1 of RFC7915 says:

>If an IPv6 packet that is smaller than or equal to 1280 bytes results
>(after translation) in an IPv4 packet that is larger than the MTU of
>the next-hop interface, then the translator MUST perform IPv4
>fragmentation on that packet such that it can be transferred over the
>constricting link.

There are related but different issues for IPv4 to IPv6 translation,
covered in section 4 of RFC7915:

>However, when the IPv4 sender does not set the DF bit, the translator
>MUST ensure that the packet does not exceed the path MTU on the IPv6
>side.  This is done by fragmenting the IPv4 packet (with Fragment
>Headers) so that it fits in 1280-byte IPv6 packets, since that is the
>minimum IPv6 MTU.

This topic might be worth mentioning, for example in the section
"For Middle Box Developers" since NAT64/NAT46 are middleboxes.

Regards
   Brian

On 2018-11-22 03:27, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Internet Area Working Group WG of the IETF.
> 
> Title   : IP Fragmentation Considered Fragile
> Authors : Ron Bonica
>   Fred Baker
>   Geoff Huston
>   Robert M. Hinden
>   Ole Troan
>   Fernando Gont
>   Filename: draft-ietf-intarea-frag-fragile-03.txt
>   Pages   : 24
>   Date: 2018-11-21
> 
> Abstract:
>This document describes IP fragmentation and explains how it reduces
>the reliability of Internet communication.
> 
>This document also proposes alternatives to IP fragmentation and
>provides recommendations for developers and network operators.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-03
> https://datatracker.ietf.org/doc/html/draft-ietf-intarea-frag-fragile-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-frag-fragile-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Stateless devices and IP fragmentation

[Brian E Carpenter]

On 2018-11-17 04:02, Ron Bonica wrote:
> Hi Brian,
> 
> Fair enough. Does the following text work?

Yes, I guess so, in the context of this section. From a user point
of view, there's an impression that we're saying that it's OK for
some cheapskate operator to break connectivity by dropping fragments,
when some other cheapskate operator has set a low MTU. But that
discussion probably belongs in a higher level section of the
document.

So: I think the document should say much more emphatically that
there is no exception to the 1280 requirement for every IPv6 hop.
It's mentioned briefly but maybe it should be underlined three times :-).

Amd maybe, since the draft is aimed at BCP, we could even go so far as
to change this assumption into a SHOULD, if not a MUST:

>So, for the purposes of this document, we assume that the IPv4
>minimum link MTU is 576 bytes.
Regards
Brian

> 
>Ron
> 
> 7.3.  For Middle Box Developers
> 
> Middle boxes SHOULD process IP fragments in a manner that is compliant with 
> RFC 791 and RFC 8200. In many cases, middle boxes must maintain state in 
> order to achieve this goal.
> 
> Price and performance considerations frequently motivate network operators to 
> deploy stateless middle boxes.  These stateless middle boxes may perform 
> sub-optimally, process IP fragments in a manner that is not compliant with 
> RFC 791 or RFC 8200, or even discard IP fragments completely. Providers of 
> such middle boxes MUST document product's their behavior.
> 
> The behaviors exhibited by the above-mentioned devices are not desirable. 
> However, one behavior may be acceptable to one network operator while another 
> behavior is acceptable to another network operator. Middle box vendors MUST 
> provide network operators with all of the information required to  make 
> intelligent middle box deployment decisions.
> 
>> -Original Message-
>> From: Brian E Carpenter 
>> Sent: Thursday, November 15, 2018 10:44 PM
>> To: Ron Bonica ; Tom Herbert
>> ; Joe Touch 
>> Cc: int-area 
>> Subject: Re: [Int-area] Stateless devices and IP fragmentation
>>
>>>  These stateless middle boxes may perform sub-optimally or process IP
>>> fragments in a manner that is not compliant with RFC 791 or RFC 8200.
>>
>> That seems to skirt round the real concern. Middleboxes don't exist in the
>> world assumed by RFC 791 or 8200, so those RFCs don't place any compliance
>> requirements on middleboxes. It's simply implicit that datagrams get 
>> delivered
>> whether fragmented or not. RFC 1812 doesn't seem to mention that routers
>> MUST forward fragments, presumably because it's blindingly obvious. Same
>> for draft-ietf-6man-rfc6434-bis and draft-v6ops-ipv6rtr-reqs.
>>
>> So at least can we say:
>>
>> These stateless middle boxes may perform sub-optimally, process IP fragments
>> in a manner that is not compliant with RFC 791 or RFC 8200, or even discard
>> IP fragments completely.
>>
>> Regards
>>Brian
>>
>> On 2018-11-16 10:35, Ron Bonica wrote:
>>> Tom, Joe, Brian,
>>>
>>> I haven't seen a response to this message. Can I assume that you are OK with
>> this text?
>>>
>>>  Ron
>>>
>>>
>>>> -Original Message-
>>>> From: Ron Bonica
>>>> Sent: Wednesday, November 14, 2018 4:35 PM
>>>> To: Tom Herbert 
>>>> Cc: int-area ; Joe Touch 
>>>> Subject: RE: [Int-area] Stateless devices and IP fragmentation
>>>>
>>>> Folks,
>>>>
>>>> We thrashing over the example. Can everybody agree to the following
>> text?
>>>>
>>>>Ron
>>>>
>>>> 7.3.  For Middle Box Developers
>>>>
>>>> Middle boxes SHOULD process IP fragments in a manner that is
>>>> compliant with RFC 791 and RFC 8200. In many cases, middle boxes must
>>>> maintain state in order to achieve this goal.
>>>>
>>>> Price and performance considerations frequently motivate network
>>>> operators to deploy stateless middle boxes. These stateless middle
>>>> boxes may perform sub-optimally or process IP fragments in a manner
>>>> that is not compliant with RFC 791 or RFC 8200. Providers of such
>>>> middle boxes MUST document product's their behavior.
>>>>
>>>> The behaviors exhibited by the above-mentioned devices are not desirable.
>>>> However, one behavior may be acceptable to one network operator while
>>>> another behavior is acceptable to another network operator. Middle
>>>> box vendors MUST provide network operators with all of the
>>>> information required to  make intelligent middle box deployment decisions.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Stateless devices and IP fragmentation

[Brian E Carpenter]

>  These stateless middle boxes may perform
> sub-optimally or process IP fragments in a manner that is not compliant with
> RFC 791 or RFC 8200.

That seems to skirt round the real concern. Middleboxes don't exist in
the world assumed by RFC 791 or 8200, so those RFCs don't place any
compliance requirements on middleboxes. It's simply implicit that datagrams
get delivered whether fragmented or not. RFC 1812 doesn't seem to mention
that routers MUST forward fragments, presumably because it's blindingly
obvious. Same for draft-ietf-6man-rfc6434-bis and draft-v6ops-ipv6rtr-reqs.

So at least can we say:

These stateless middle boxes may perform
sub-optimally, process IP fragments in a manner that is not compliant with
RFC 791 or RFC 8200, or even discard IP fragments completely.

Regards
   Brian

On 2018-11-16 10:35, Ron Bonica wrote:
> Tom, Joe, Brian,
> 
> I haven't seen a response to this message. Can I assume that you are OK with 
> this text?
> 
>  Ron
> 
> 
>> -Original Message-
>> From: Ron Bonica
>> Sent: Wednesday, November 14, 2018 4:35 PM
>> To: Tom Herbert 
>> Cc: int-area ; Joe Touch 
>> Subject: RE: [Int-area] Stateless devices and IP fragmentation
>>
>> Folks,
>>
>> We thrashing over the example. Can everybody agree to the following text?
>>
>>Ron
>>
>> 7.3.  For Middle Box Developers
>>
>> Middle boxes SHOULD process IP fragments in a manner that is compliant with
>> RFC 791 and RFC 8200. In many cases, middle boxes must maintain state in
>> order to achieve this goal.
>>
>> Price and performance considerations frequently motivate network operators
>> to deploy stateless middle boxes. These stateless middle boxes may perform
>> sub-optimally or process IP fragments in a manner that is not compliant with
>> RFC 791 or RFC 8200. Providers of such middle boxes MUST document
>> product's their behavior.
>>
>> The behaviors exhibited by the above-mentioned devices are not desirable.
>> However, one behavior may be acceptable to one network operator while
>> another behavior is acceptable to another network operator. Middle box
>> vendors MUST provide network operators with all of the information required
>> to  make intelligent middle box deployment decisions.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] About limited domains (2)

[Brian E Carpenter]

On 2018-11-16 08:41, Tom Herbert wrote:
> On Mon, Nov 12, 2018 at 4:22 PM Brian E Carpenter
>  wrote:
>>
>> Quoting the minutes on draft-carpenter-limited-domains-04:
>>
>>> RV: The hints that I'm hearing are that if you have well structured systems 
>>> there are infinite ways to break the structure. If one allows people in the 
>>> wild to
>>> do whatever they want, you get trends like this. It's not a trend you want 
>>> to support.
>>
>> Our point is not about people doing things in the wild; it's about people 
>> doing things inside a particular domain (a.k.a. environment). We (the IETF) 
>> can't stop that, but we can in theory standardise technology to define the 
>> domain and make it secure.
> 
> Hi Brian,
> 
> I don't think it's a question of trying to stop people from doing
> whatever they want, I think it's more of a question of whether IETF
> should be encouraging such behavior.

I don't think any encouragement is needed; it will happen anyway. I think
we're making a different argument: How to ensure that private or limited
scope deployments are properly confined and do not cause problems outside
their scope.

> 
>>From the draft:
> 
> "Nevertheless, because of the diversity of limited environments with
> specific requirements that is now emerging, specific standards will
> necessarily emerge."
> 
> I don't think the necessity that specific standards need to be defined
> for limited domains has been established. For discussion, can you give
> a specific example of a required protocol that would only work in a
> limited domain, but would be incorrect if used in the Internet?

Well, we have some to hand: any diffserv PHB is an example, unless
inter-ISP agreements are in place at every ISP-ISP boundary on the
path. Specifically consider the codepoint properly defined as CS1
(class selector 1, the same as legacy TOS precedence 1), that has been
widely used for the Lower Effort per-hop behaviour instead. That
simply doesn't work properly across domain boundaries if the two
domains use different interpretations of the same codepoint (hence
draft-ietf-tsvwg-le-phb). 

As I understand DETNET, that will be similar. I think there
are other cases mentioned in the draft too.

But you're right in the sense that it really doesn't affect our
premise whether the local protocol (or extension, or codepoint)
is an IETF standard, an "XYZ Forum" standard, or simply an
in-house development. If it needs to be confined to a given domain,
there needs to be a mechanism for doing so.

   Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Stateless devices and IP fragmentation

[Brian E Carpenter]

On 2018-11-15 10:54, Tom Herbert wrote:
> On Wed, Nov 14, 2018 at 1:25 PM, Brian E Carpenter
>  wrote:
>> On 2018-11-15 10:02, Tom Herbert wrote:
>>> On Wed, Nov 14, 2018 at 12:50 PM, Ron Bonica  wrote:
>>>> Tom,
>>>>
>>>> Please look inline for a little compromise and a little pushback. I hope 
>>>> that we can reach consensus in this round.
>>>>
>>>>  Ron
>>>>
>>>>
>>>>> -Original Message-
>>>>> From: Tom Herbert 
>>>>> Sent: Wednesday, November 14, 2018 3:02 PM
>>>>> To: Ron Bonica 
>>>>> Cc: int-area ; Joe Touch 
>>>>> Subject: Re: [Int-area] Stateless devices and IP fragmentation
>>>>>
>>>>> On Wed, Nov 14, 2018 at 11:35 AM, Ron Bonica 
>>>>> wrote:
>>>>>> Folks,
>>>>>>
>>>>>> Since we seem to have reached consensus on Section 7.1, let's take 
>>>>>> another
>>>>> stab at Section 7.3. I am looking particularly to Tom Herbert and Joe 
>>>>> Touch for
>>>>> feedback, since they objected to the previous formulation.
>>>>>>
>>>>>> Proposed text follows
>>>>>>
>>>>>>Ron
>>>>>>
>>>>>> 7.3.  For Middle Box Developers
>>>>>>
>>>>>> Middle boxes SHOULD process IP fragments in a manner that is compliant
>>>>> with RFC 791 and RFC 8200. In many cases, middle boxes must maintain state
>>>>> in order to achieve this goal.
>>>>>>
>>>>>> Price and performance considerations frequently motivate network
>>>>> operators to deploy stateless middle boxes. These stateless middle boxes 
>>>>> may
>>>>> perform sub-optimally or process IP fragments in a manner that is not
>>>>> compliant with RFC 791 or RFC 8200. Providers of such middle boxes MUST
>>>>> document product's their behavior.
>>>>>
>>>>> Hi Ron,
>>>>>
>>>>> Maybe s/may/sometimes/ to avoid any hint that we're advocating non-
>>>>> compliant behavior.
>>>>>
>>>>
>>>> Fair enough, change accepted.
>>>>
>>>>>>
>>>>>> For example, a network operator may be motivated to deploy a stateless
>>>>> load balancer. Because the load balancer is stateless, it is likely to 
>>>>> exhibit on of
>>>>> the following behaviors:
>>>>>>
>>>>>> - For all packets, implement a load balancing algorithm whose inputs are
>>>>> drawn from the IP header. This algorithm facilitates RFC compliant 
>>>>> behavior.
>>>>> However,  it may distribute load unevenly.
>>>>>
>>>>> I don't think I would phrase it this way. It might be more along the 
>>>>> lines that if
>>>>> load balancer takes into account transport layer information then it 
>>>>> usually
>>>>> performs better. Also, in the case of IPv6 the flowlabel is part of IP 
>>>>> header and
>>>>> could be used to achieve similar load balancing characteristics as the 
>>>>> case that
>>>>> the transport ports are considered. So this statement might only be 
>>>>> applicable
>>>>> to IPv4.
>>>>
>>>>
>>>> How does the following text strike you..
>>>>
>>>> - For all packets, implement a load balancing algorithm whose inputs are 
>>>> drawn from the IP header. This algorithm facilitates RFC compliant 
>>>> behavior. However, this algorithm may not distribute load as evenly as 
>>>> another algorithm whose inputs  are drawn from the IP and transport layer 
>>>> headers.
>>>>
>>>> I am going to push back on the flow label part because a) it is not 
>>>> available in IPv4 and b) In IPv6, we have no guarantee that it will be 
>>>> set. So, I weasel around the issue by saying that the algorithm *may* not 
>>>> distribute load as evenly. I never say that it *will* not distribute load 
>>>> as evenly.
>>>
>>> I believe flow label is now being set by all major OSes. Even if it's
>>> not set, the algorithm just falls back to hashing over IP a

Re: [Int-area] Stateless devices and IP fragmentation

[Brian E Carpenter]

On 2018-11-15 10:02, Tom Herbert wrote:
> On Wed, Nov 14, 2018 at 12:50 PM, Ron Bonica  wrote:
>> Tom,
>>
>> Please look inline for a little compromise and a little pushback. I hope 
>> that we can reach consensus in this round.
>>
>>  Ron
>>
>>
>>> -Original Message-
>>> From: Tom Herbert 
>>> Sent: Wednesday, November 14, 2018 3:02 PM
>>> To: Ron Bonica 
>>> Cc: int-area ; Joe Touch 
>>> Subject: Re: [Int-area] Stateless devices and IP fragmentation
>>>
>>> On Wed, Nov 14, 2018 at 11:35 AM, Ron Bonica 
>>> wrote:
 Folks,

 Since we seem to have reached consensus on Section 7.1, let's take another
>>> stab at Section 7.3. I am looking particularly to Tom Herbert and Joe Touch 
>>> for
>>> feedback, since they objected to the previous formulation.

 Proposed text follows

Ron

 7.3.  For Middle Box Developers

 Middle boxes SHOULD process IP fragments in a manner that is compliant
>>> with RFC 791 and RFC 8200. In many cases, middle boxes must maintain state
>>> in order to achieve this goal.

 Price and performance considerations frequently motivate network
>>> operators to deploy stateless middle boxes. These stateless middle boxes may
>>> perform sub-optimally or process IP fragments in a manner that is not
>>> compliant with RFC 791 or RFC 8200. Providers of such middle boxes MUST
>>> document product's their behavior.
>>>
>>> Hi Ron,
>>>
>>> Maybe s/may/sometimes/ to avoid any hint that we're advocating non-
>>> compliant behavior.
>>>
>>
>> Fair enough, change accepted.
>>

 For example, a network operator may be motivated to deploy a stateless
>>> load balancer. Because the load balancer is stateless, it is likely to 
>>> exhibit on of
>>> the following behaviors:

 - For all packets, implement a load balancing algorithm whose inputs are
>>> drawn from the IP header. This algorithm facilitates RFC compliant behavior.
>>> However,  it may distribute load unevenly.
>>>
>>> I don't think I would phrase it this way. It might be more along the lines 
>>> that if
>>> load balancer takes into account transport layer information then it usually
>>> performs better. Also, in the case of IPv6 the flowlabel is part of IP 
>>> header and
>>> could be used to achieve similar load balancing characteristics as the case 
>>> that
>>> the transport ports are considered. So this statement might only be 
>>> applicable
>>> to IPv4.
>>
>>
>> How does the following text strike you..
>>
>> - For all packets, implement a load balancing algorithm whose inputs are 
>> drawn from the IP header. This algorithm facilitates RFC compliant behavior. 
>> However, this algorithm may not distribute load as evenly as another 
>> algorithm whose inputs  are drawn from the IP and transport layer headers.
>>
>> I am going to push back on the flow label part because a) it is not 
>> available in IPv4 and b) In IPv6, we have no guarantee that it will be set. 
>> So, I weasel around the issue by saying that the algorithm *may* not 
>> distribute load as evenly. I never say that it *will* not distribute load as 
>> evenly.
> 
> I believe flow label is now being set by all major OSes. Even if it's
> not set, the algorithm just falls back to hashing over IP addresses.
> Flow label was a good addition to IPv6 exactly for the purposes of
> things like load balancing and it solves the problem in this case.
> It's use should be encouraged here.

To be clear, if you do ECMP or LAG based entirely on the 3-tuple
{dest_addr, source_addr, flow_label} then fragments will all follow
exactly the same path as unfragmented packets. So, perfection.
This is true even if the flow label is zero, of course.

Trying to use the traditional 5-tuple will not work well with
fragments.

It's more complicated at the server farm end.
 "Moreover, the transport-layer
  information such as the source port is not repeated in fragments,
  which generally prevents stateless load balancers from supporting
  fragmented traffic since they generally cannot reassemble
  fragments."  [RFC7098].

Brian


> 
>>
>>

 - For fragmented packets, implement a load balancing algorithm whose
>>> inputs are drawn from the IP header. For non-fragmented packets, implement
>>> a load balancing algorithm whose inputs are drawn from the IP header and
>>> the Layer 4 header.  This algorithm facilitates RFC compliant behavior. It 
>>> also
>>> improves load distribution for flows that do not included fragmented 
>>> packets.
>>> However, if a flow contains fragmented packets, packets belonging to that
>>> flow can be distributed between two different outgoing interfaces.
>>>
>>> Again, this would only be relevant in IPv4, for IPv6 flow label solves the
>>> problem. For IPv4, I think this algorithm is about a best as could be done. 
>>> It
>>> might be worth mentioning that all fragments of a packet, 

Re: [Int-area] Stateless devices and IP fragmentation

[Brian E Carpenter]

On 2018-11-15 09:31, Ole Troan wrote:
> Tom,
> 
>> I don't believe this can be true. Not all protocols even have port
>> numbers (e.g. ICMP, ESP) and yet we still expect them to be
>> deliverable. Maybe your referring to ECMP, which does route based on
>> flow (e.g. port information)? But, ECMP is not required to make IP
>> work either. Forwarding solely based on destination IPv4 address for
>> unicast packets needs to work.
> 
> I can’t see how you can expect anything but TCP and UDP and (some) ICMP to be 
> deliverable.
> These just do not pass through stuff like A+P, CGNs.
> 
> Of course you can pass non TCP/UDP through limited domains, but you cannot 
> expect that to work across the Internet anymore.

You mean the IPv4nternet, I hope ;-).

   Brian

> Cheers,
> Ole
> 
> 
>>
>>> I.e it’s now part of ‘normal’ routing/forwarding. That’s absolutely not the 
>>> case. In IPv6 packets are delivered to hosts based on longest match on 
>>> destination addresses, while for IPv4 it’s a match IPv4 DA and DP.
>>
>> ECMP is also done for IPv6. I don't see how routing is fundamentally
>> different in IPv6 except that the flow label could be a good
>> substitute for ports in ECMP.
>>
>> Tom
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Stateless devices and IP fragmentation

[Brian E Carpenter]

On 2018-11-13 13:27, Tom Herbert wrote:
> On Mon, Nov 12, 2018 at 3:56 PM, Ron Bonica  wrote:
>> Tom,
>>
>> OK. Let's see if the following text works any better for you.
>>
>> Ron
>> 
>> 7.1.  For Protocol Developers
>>
>>Protocol developers SHOULD NOT develop new protocols that rely
>>on IP fragmentation. However, they MAY develop new protocols that
>>rely on IP fragmentation when no viable alternative exists.
>>
>>Legacy protocols that depend upon IPv6 fragmentation SHOULD be updated
>>to break that dependency.  However, in some cases, there may be no viable
>>alternative to IPv6 fragmentation (e.g., IPSec tunnel mode, IP-in-IP 
>> encapsulation).
>>In these cases, the protocol MAY continue to rely on IPv6 fragmentation.
>>
>>A protocol can break its dependency upon IP fragmentation by
>>using a sufficiently small MTU (e.g.  the protocol minimum link MTU),
>>disabling IP fragmentation, and ensuring that the transport protocol in
>>use adapts its segment size to the MTU.  Another approach is to deploy
>>a sufficiently reliable PMTU discovery mechanism (e.g., PLMPTUD).
>>
> 
> Hi Ron.
> 
>> 7.3.  For Middle Box Developers

I agree with all of Tom's comments below, but also think that this
tries to roll too many different functions into one class. Server
load balancing is a very different thing from ISP load balancing,
and is unlikely to be stateless, so one size of recommendation
definitely doesn't fit all.

Brian

>>
>>  Middle box developers SHOULD implement devices that process IP fragments in 
>> a predictable manner.
>>  For example,  a stateless load balancer might exhibit one of the following 
>> behaviors:
>>
> Seems like you're offering middle box developers a choice amonst
> different behaviors. May this "consistent" as opposed to "pedictable"
> behavior.
> 
>> - Balance load based on L3 information only
>>
> 
> Probably want to be more specific here, presumably this means hash
> over pair of addresses.
> 
> Load balance over 3-tuple of IP address and flow label should have its
> own recommendation. This is effectively operating on L4 information.
> 
>> - Balance load based upon both L3 and L4 information, but discard all IP 
>> fragments
>>
> Which pretty much makes fragmentation useless, so it's not a great
> recommendation. There's another problem here in that L4 information
> might not be available in other types of packets. When we say L4, what
> that probably means is just plain TCP or UDP packets.
> 
>> - For non-fragmented packets, balance load upon both L3 and L4 information. 
>> For fragmented packets, balance load based upon L3 information only. 
>> Therefore, packets belonging to a single flow can be assigned to two 
>> different interfaces. (See Section 4.4 for details).
> 
> It depends on what the backend of the load balancer is doing. If it is
> an L4 load balancer to VIPs, then fragments and non-fragments for a
> flow have to go to the same node.
> 
>>
>> - Balance load based upon both L3 and L4 information,  but maintain enough 
>> state so that all packets and packet fragments belonging to a flow are 
>> assigned to the same interface.
> 
> Sure, but then the device can no longer be called stateless. AFAICT
> using the flow label in the hash is the only way that a stateless L4
> load balancer could get a consistent hash between fragments and
> non-fragments.
> 
> Tom
> 
>>
>> Undesirable outcomes can be attributed to each of the above mentioned 
>> behaviors. Therefore, middle box vendors MUST document the behaviors that 
>> their devices exhibit.
>>
>>
>>
>>
>>> -Original Message-
>>> From: Tom Herbert 
>>> Sent: Monday, November 12, 2018 4:25 PM
>>> To: Ron Bonica 
>>> Cc: Joe Touch ; Ole Troan
>>> ; int-area 
>>> Subject: Re: [Int-area] Stateless devices and IP fragmentation
>>>
>>> On Mon, Nov 12, 2018 at 1:08 PM, Ron Bonica  wrote:
 Joe, Tom,

 Does the following text work for you?

 Ron

 ===


 7.1.  For Protocol Developers

Protocol developers SHOULD NOT develop new protocols that rely
on IP fragmentation. However, they MAY develop new protocols that
rely on IP fragmentation when no viable alternative exists.

Legacy protocols that depend upon IPv6 fragmentation SHOULD be
>>> updated
to break that dependency.  However, in some cases, there may be no
>>> viable
alternative to IPv6 fragmentation (e.g., IPSec tunnel mode, IP-in-IP
>>> encapsulation).
In these cases, the protocol MAY continue to rely on IPv6 fragmentation.

A protocol can break its dependency upon IP fragmentation by
using a sufficiently small MTU (e.g.  the protocol minimum link MTU),
disabling IP fragmentation, and ensuring that the transport protocol in
use 

[Int-area] About limited domains (2)

[Brian E Carpenter]

Quoting the minutes on draft-carpenter-limited-domains-04:

> RV: The hints that I'm hearing are that if you have well structured systems 
> there are infinite ways to break the structure. If one allows people in the 
> wild to
> do whatever they want, you get trends like this. It's not a trend you want to 
> support.

Our point is not about people doing things in the wild; it's about people doing 
things inside a particular domain (a.k.a. environment). We (the IETF) can't 
stop that, but we can in theory standardise technology to define the domain and 
make it secure.

Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] About limited domains

[Brian E Carpenter]

Quoting the minutes on draft-carpenter-limited-domains-04:

> EK: This looks like a way to get execptions for things you otherwise wouldn't 
> be allowed to do. Sometimes things jump domains. I don't think I agree 
> philiosophically that this is 
> a good idea.

Unfortunately I wasn't on meetecho due to a combination of illness and the time 
zone. Our argument is basically that it doesn't matter whether it's a good 
idea, because it is already normal practice and is in fact built in to existing 
IETF work. (David Black's point about 'controlled environment' terminology 
underlines this.) So the question really is how to deal with it from the point 
of view of operations, security and the impact on interoperability.

My bet is that this will become much more important in future.

Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt

[Brian E Carpenter]

On 2018-10-16 11:26, Tom Herbert wrote:
> 
> 
> On Mon, Oct 15, 2018, 3:11 PM Fred Baker  > wrote:
> 
> 
> 
> > On Oct 15, 2018, at 1:50 PM, Ron Bonica  > wrote:
> >
> > Exactly, but I didn't want to introduce and define the term "Virtual 
> Fragment Reassembly". So, I just described the output. The middle box:
> >
> > - makes a decision on that first fragment
> 
> The one at offset 0 (and therefore containing the transport header), or 
> the first one it receives (which might be at the final offset or any other)? 
> What if they're not the same?
> 
> 
> For instance, a while back Linux always sent the first fragment last when 
> fragmenting. This wreaked havoc on middle boxes trying to reassemble. That 
> was changed to send first fragment first. But even so, I think there might be 
> some ECMP implementations that could route first fragment (off=0) differently 
> to create ooo packets relative to fragment train.

Clearly, at some stage we had the hope that the flow label would be useful to 
mitigate this sort of problem. It's intentionally included in every IPv6 
fragment.

   Brian

> 
> Tom
> 
> 
> > - applies that decision to the first fragment and all subsequent 
> fragments
> >
> >                                                  Ron
> >
> >
> >> -Original Message-
> >> From: Templin (US), Fred L  >
> >> Sent: Monday, October 15, 2018 4:46 PM
> >> To: Ron Bonica mailto:rbon...@juniper.net>>; 
> Fred Baker
> >> mailto:fredbaker.i...@gmail.com>>
> >> Cc: int-area@ietf.org 
> >> Subject: RE: [Int-area] I-D Action: 
> draft-ietf-intarea-frag-fragile-01.txt
> >>
> >> Hi Ron,
> >>
> >> There is a technique known as "Virtual Fragmentation Reassembly" where 
> the
> >> middlebox gathers all fragments of a datagram, performs any necessary
> >> checks and then releases the fragments without reassembling them so 
> that the
> >> destination host still has to reassemble. Is this one of the 
> techniques you are
> >> referring to?
> >>
> >> Thanks - Fred
> >>
> >>> -Original Message-
> >>> From: Int-area [mailto:int-area-boun...@ietf.org 
> ] On Behalf Of Ron
> >>> Bonica
> >>> Sent: Monday, October 15, 2018 1:39 PM
> >>> To: Fred Baker  >
> >>> Cc: int-area@ietf.org 
> >>> Subject: Re: [Int-area] I-D Action:
> >>> draft-ietf-intarea-frag-fragile-01.txt
> >>>
> >>> Hi Fred,
> >>>
> >>> The first iteration of Section 7.3 actually included the word 
> "reassemble".
> >> That is one possible implementation.
> >>>
> >>> I dropped the word when I realized that there may be other ways to get
> >>> the desired behavior. While they don't all require reassembly, that 
> all require
> >> the maintenance of a little more state.
> >>>
> >>>
> >>> Ron
> >>>
> >>>
>  -Original Message-
>  From: Fred Baker  >
>  Sent: Monday, October 15, 2018 3:50 PM
>  To: Ron Bonica mailto:rbon...@juniper.net>>
>  Cc: int-area@ietf.org 
>  Subject: Re: [Int-area] I-D Action:
>  draft-ietf-intarea-frag-fragile-01.txt
> 
> 
> 
> > On Oct 15, 2018, at 12:11 PM, Ron Bonica  >
> >> wrote:
> >
> > So, the spirit of the robustness principle, all parties should be
> > conservative in
>  what they do and liberal in what they accept.
> >
> > - Application developers should avoid reliance on IP
> > Fragmentation. (Don't
>  trip on the bad behavior or middle boxes if you can avoid it).
> > - Middle box developers should produce devices that don't behave
> > badly in
>  the presence of fragmentation. This may mean that middle boxes
>  should become more stateful to support fragmentation.
> 
>  I might add one thought to 7.3: recommend that middle boxen
>  reassemble a datagram before operating on it. The attacks that
>  happen with fragmentation result in issues with reassembly, and the
>  obvious solution is to detect the situation and drop the datagram in
> >> question.
> 
>  I would also comment that the first fragment created (the one at
>  offset zero) might not be the first fragment received. The second
>  bullet in 7.3, the one about selecting a next-hop, assumes that the
>  first fragment is also the first one received. However, if the
>  datagram were reassembled before operating on it, that wouldn't be an
> >> issue.
> >>>
> >>> 

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt

[Brian E Carpenter]

On 2018-10-16 09:35, Ron Bonica wrote:
> Hi Tom,
> 
> The examples in Sections 4.1-4.4 all refer to stateless devices. The problem 
> could be solved by making them all stateful. However, that may not be 
> practical because of:
> 
> - price/performance concerns
> - size of the installed base.
> 
> Years back, Tom Taylor and others speculated on why operators drop fragmented 
> packets. This work was never complete.

I seem to recall that the speculation was that they drop fragments (after the 
first one) because they cannot meaningfully apply firewall rules to it, since 
the layer 4 header is absent. So better safe than sorry.

(Obviously - that is a stateless mechanism, with the decision taken at line 
speed.)

However, in RFC3234 (February 2002) we wrote this:

   "Stateless" firewalls typically allow all IP fragments through since
   they do not contain enough upper-layer header information to make a
   filtering decision.  Many "stateful" firewalls therefore reassemble
   IP fragments (and re-fragment if necessary) in order to avoid leaking
   fragments, particularly fragments that may exploit bugs in the
   reassembly implementations of end receivers.

I assume we had some basis for those factual claims, but I don't see anything 
in my archive.

   Brian


> 
> Ron
> 
> 
>> -Original Message-
>> From: Tom Herbert 
>> Sent: Monday, October 15, 2018 3:31 PM
>> To: Ron Bonica 
>> Cc: int-area@ietf.org
>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
>>
>> On Mon, Oct 15, 2018 at 12:11 PM, Ron Bonica 
>> wrote:
>>> Hi Tom,
>>>
>>> Hope you are feeling better. Comments inline.
>>>
>>>   Ron
>>>
>>>
 Message: 1
 Date: Wed, 10 Oct 2018 13:55:16 -0700
 From: Tom Herbert 
 To: int-area 
 Subject: Re: [Int-area] I-D Action:
   draft-ietf-intarea-frag-fragile-01.txt
 Message-ID:
   >>> il.gmail.com>
 Content-Type: text/plain; charset="UTF-8"

 Thanks for the updated draft. Here are a few comments:

 "While this document identifies issues associated with IP
 fragmentation, it does not recommend deprecation.  Some applications
 (e.g., [I-D.ietf-intarea-
 tunnels]) require IP fragmentation."

 I would add that use of fragmentation is also expected to work and be
 common in limited domains where issues in security and
 interoperability in intermediate nodes can be addressed,
>>>
>>> Fair enough. Does the following edit work for you
>>>
>>> OLD>
>>>While this document identifies issues associated with IP
>>>fragmentation, it does not recommend deprecation.  Some applications
>>>(e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation.
>>> >>
>>> NEW>
>>>While this document identifies issues associated with IP
>>>fragmentation, it does not recommend deprecation.  Some applications
>>>(e.g., [I-D.ietf-intarea-tunnels]) require IP fragmentation. Furthermore,
>>>fragmentation is expected to work in limited domains where security and
>> interoperability
>>>issues can be addressed.
>>> >
>> It's good.
>>
>>>
>>>

 >From the draft: "This section explains how IP fragmentation reduces
 the reliability of Internet communication." In reality, for most of
 the examples in this section it's really implementations (NAT,
 firewall, etc.) that are breaking IP fragmentation (and other things as 
 well).

 Sections 4.1-4.4 could be summarized to say that some intermediate
 devices perform functions based on inspecting transport layer
 headers, and these fail when fragments are presented that don't
 contain the transport layer information. This could be further
 subdivided into stateful and stateless mechanisms. Policy routing,
 firewalls, NAT are just examples of functions that break with
>> fragmentation.
>>>
>>> This is insightful!
>>>
>>> The draft can be summarized as follows:
>>>
>>> - IP fragmentation is a stateful procedure in an otherwise stateless 
>>> protocol.
>>> - When the end-to-end principle was in force, fragmentation worked well.
>> The stateful process was relegated to the endpoints and everything just
>> worked.
>>> - As years went by, vendors built stateless middle boxes. Being stateless, 
>>> they
>> offer good performance at an attractive price. However, being stateless, they
>> are oblivious to fragmentation and behave badly in the presence of fragments.
>>
>> I don't follow. Isn't the problem with _stateful_ devices, or at least
>> intermediate devices that choose to parse transport layer.
>>
>>> - These stateless middle boxes are very widely deployed. Because they are
>> economically attractive, even more of them are likely to be deployed in the
>> future.
>>
>> A stateless middlebox that doesn't parse transport layer should work 
>> perfectly
>> well with fragmentation. This would describe a device adhering to end to end
>> model.
>>
>>>
>>> So, the 

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-04.txt

[Brian E Carpenter]

Hi,

We have significantly updated this draft, with some reorganization
of existing material, and two new sections added:
6. The Scope of Protocols in Limited Domains
7. Functional Requirements of Limited Domains

We suggest discussion on the int-area@ietf.org list.

   Brian + Bing


 Forwarded Message 
Subject: I-D Action: draft-carpenter-limited-domains-04.txt
Date: Sun, 14 Oct 2018 12:32:36 -0700
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Limited Domains and Internet Protocols
Authors : Brian Carpenter
  Bing Liu
Filename: draft-carpenter-limited-domains-04.txt
Pages   : 22
Date: 2018-10-14

Abstract:
   There is a noticeable trend towards network requirements, behaviours
   and semantics that are specific to a limited region of the Internet
   and a particular set of requirements.  Policies, default parameters,
   the options supported, the style of network management and security
   requirements may vary.  This document reviews examples of such
   limited domains and emerging solutions, and develops a related
   taxonomy.  It then briefly discusses the standardization of protocols
   for limited domains.  Finally, it shows the needs for a precise
   definition of limited domain membership and for mechanisms to allow
   nodes to join a domain securely and to find other members, including
   boundary nodes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-limited-domains-04
https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt

[Brian E Carpenter]

Just picking on one part of Tom's excellent note:

On 2018-09-13 11:14, Tom Herbert wrote:

> IMO, IETF's strength and advantage is that it focuses on standardizing
> protocols without standardizing network architecture. This provides
> all the necessary freedom for to build networks as appropriate and
> encourage innovation on many fronts. For the most part this model
> seems to haved worked well.

Well, I think we have counter-examples. PMTUD failure for one. Opaqueness
of the Internet to new IPv6 extension headers for another. The strong
desire from some operators to deploy locally-significant extensions
in a standardized way for another. And we've developed solutions
already, dating back at least to SOCKS. So haven't we been implicitly
pretending that this elephant wasn't in the room?

Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt

[Brian E Carpenter]

Tom,

On 2018-09-13 04:10, Tom Herbert wrote:
> Hi Brian,
> 
> Thanks for the draft!
> 
> I am still concerned about the implications and perceptions this draft
> might entail. Particularly, I wonder whether this will fracture the
> Internet (even more) and encourage (even more) protocol ossification
> by allowing developers and protocol designers to take short cuts that
> skimp on interoperability and use proprietary solutions instead of
> investing in open ones (with the vendor lock-in that goes with that).

Of course that's a concern. My personal opinion is since it's going to
happen anyway (in fact, has been happening for many years in reality),
we are better off to bite the bullet and face reality. If the IoT is
anything real, it means we're going to make the Internet 100 times bigger
and that seems inconceivable without limited domains at the edges.

> Consider this from the draft:
> 
> "This section suggests that protocols or protocol extensions should,
> when appropriate, be standardised to interoperate only within a
> Limited Domain Boundary.  Such protocols are not required to operate
> across the Internet as a whole."
> 
> I'm not sure what "not required to operate across the Internet as a
> whole" means. Specifically, what does it mean for a protocol to not
> have to "operate" on the whole Internet.

Yes, this area needs more work. Our idea was to do that next, after
getting the taxonomy into shape. Your comments below are very insightful
and help a lot. Just one specific comment below at this point.

> I think there are three
> possible meanings here: 1) using the protocol across the whole
> Internet isn't useful because it depends on localized information 2)
> using the protocol on the Internet isn't feasible because there is a
> lack of global support for it in the Internet 3) using the protocol on
> the whole Internet isn't correct and leads to bad behaviors. Example
> of #1 is segment routing, example of #2 is IPv6 extension headers, and
> example of #3 is extension header insertion. Of the three
> possibilities, an incorrect protocol is the most problematic. As a
> litmus test, consider that a Limited Domain implies a security
> perimeter exists around the domain that would contain the Limited
> Domain protocol. We know that such perimeters can and will break down
> at some point so that some day a limited domain protocol will leak
> into the Internet. That cannot lead to incorrect behavior, this cannot
> break the Internet! I submit that if a protocol cannot operate
> *correctly* in the Internet, or would break correct operation of other
> protocols on the Internet, then it is _not_ an Internet protocol.
> 
> The part about "interoperate only within a Limited Domain Boundary" is
> also interesting. I worry vendors make take a lot of license with
> this. For instance, I have heard one suggestion that mobile operators
> might "give" each hardware vendor there own slice. So a Limited Domain
> is defined to contain only one vendor's equipment. Interoperability
> within a single implementation is rarely an issue! While I don't think
> it's our business to prevent things like this (network operators can
> do what they want within their domain), neither do I think we should
> be encouraging or facilitating it. IETF is fundamentally about
> standardizing open, interoperable Internet protocols. I guess the
> consequences of this is that if someone defines a protocol that only
> operates in a limited domain, then the limited domain itself needs to
> be clearly defined in normative language.

I'd go a bit further - I think we need to standardize the mechanisms
for identifying and defining the boundary, so that what happens inside
can be effectively contained. That helps everybody.

Thanks
Brian

> 
> Tom
> 
> On Tue, Sep 11, 2018 at 8:30 PM, Brian E Carpenter
>  wrote:
>> New version, with a first draft of a taxonomy added.
>>
>> Discussion welcome.
>>
>>Brian + Bing
>>
>>  Forwarded Message 
>> Subject: I-D Action: draft-carpenter-limited-domains-03.txt
>> Date: Tue, 11 Sep 2018 20:18:56 -0700
>> From: internet-dra...@ietf.org
>> Reply-To: internet-dra...@ietf.org
>> To: i-d-annou...@ietf.org
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>
>>
>> Title   : Limited Domains and Internet Protocols
>> Authors : Brian Carpenter
>>   Bing Liu
>> Filename: draft-carpenter-limited-domains-03.txt
>> Pages   : 19
>> Date: 2018-09-11
>>
>> Abstract:
>>Th

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt

[Brian E Carpenter]

Andy, and Alex,

Yes. I think we need to say more about this aspect. It's clear that
a technology boundary is a kind of "natural" domain boundary,
but on the other hand we've been overcoming such boundaries for
many years (anybody remember Ethernets bridged together over FDDI?).
And of course VLANs create limited domains at layer 2. However,
implicitly we're talking about limited domains at layer 3. Maybe we
need to be explicit about that (but see Tom Herbert's message, which
I'll reply to next).

Regards
   Brian

On 2018-09-13 04:16, Andrew G. Malis wrote:
> Alex and Brian,
> 
> Any time you have a limited domain layer 2 network (such as a campus
> Ethernet, or more application-specific networks like Alex was mentioning),
> one thing that commonly occurs is that people want to use tunnels to
> interconnect such networks either over the Internet, or alternatively over
> an enterprise's managed L3 network from a WAN service provider if they want
> to be able to maintain SLA parameters. In that  case, tunneling
> technologies such as pseudowires, L2TPv3, or GRE are commonly used. I think
> that this is a different case than the gateways mentioned by Alex, since in
> some cases there may be no IP involved except as an outer tunnel wrapper,
> or MPLS may be the outer wrapper, in which case there's no IP at all.
> 
> Brian, you started to touch on this in your draft with mentions of
> interconnections between limited domains, but you might want to add more
> detail for the reader.
> 
> Cheers,
> Andy
> 
> 
> On Wed, Sep 12, 2018 at 10:51 AM, Alexandre Petrescu <
> alexandre.petre...@gmail.com> wrote:
> 
>> I read the draft.  I find it describes well a state of matters in
>> networking along a Limited Domain paradigm.
>>
>> Maybe some call IP-enabled Limited Domains 'walled gardens'.
>>
>> 4.  Examples of Limited Domain Solutions
>>>
>>>This section lists various examples of specific limited domain
>>>solutions that have been proposed or defined.  It intentionally does
>>>not include Layer 2 technology solutions, which by definition apply
>>>to limited domains.
>>>
>>
>> But there are so many new layer 2 technology solutions that could well
>> apply to be Limited Domains.  I was just shown HDMI datagrams over Ethernet
>> without IP headers, to cite an example outside the typical Bluetooth or USB
>> network.
>>
>> I think this is a tendency that will continue: more application-specific
>> layer 2 technologies will be developped to manage more Limited Domains,
>> which will all need to be connected to the Internet in one way or another.
>>
>> At first, the connection to the Internet will be with a Gateway, and only
>> then IP will blend in.  But it's always a two-step operation. Never people
>> start make new application-specific Limited Domains networks with IP.
>>
>> Alex
>>
>>
>> Le 12/09/2018 à 05:30, Brian E Carpenter a écrit :
>>
>>> New version, with a first draft of a taxonomy added.
>>>
>>> Discussion welcome.
>>>
>>> Brian + Bing
>>>
>>>  Forwarded Message 
>>> Subject: I-D Action: draft-carpenter-limited-domains-03.txt
>>> Date: Tue, 11 Sep 2018 20:18:56 -0700
>>> From: internet-dra...@ietf.org
>>> Reply-To: internet-dra...@ietf.org
>>> To: i-d-annou...@ietf.org
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>>  Title   : Limited Domains and Internet Protocols
>>>  Authors : Brian Carpenter
>>>Bing Liu
>>> Filename: draft-carpenter-limited-domains-03.txt
>>> Pages   : 19
>>> Date: 2018-09-11
>>>
>>> Abstract:
>>> There is a noticeable trend towards network requirements, behaviours
>>> and semantics that are specific to a limited region of the Internet
>>> and a particular set of requirements.  Policies, default parameters,
>>> the options supported, the style of network management and security
>>> requirements may vary.  This document reviews examples of such
>>> limited domains and emerging solutions, and develops a related
>>> taxonomy.  It shows the needs for a precise definition of a limited
>>> domain boundary and for a corresponding protocol to allow nodes to
>>> discover where such a boundary exists.
>>>
>>>
>>> The IETF datatra

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-03.txt

[Brian E Carpenter]

New version, with a first draft of a taxonomy added.

Discussion welcome.

   Brian + Bing

 Forwarded Message 
Subject: I-D Action: draft-carpenter-limited-domains-03.txt
Date: Tue, 11 Sep 2018 20:18:56 -0700
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Limited Domains and Internet Protocols
Authors : Brian Carpenter
  Bing Liu
Filename: draft-carpenter-limited-domains-03.txt
Pages   : 19
Date: 2018-09-11

Abstract:
   There is a noticeable trend towards network requirements, behaviours
   and semantics that are specific to a limited region of the Internet
   and a particular set of requirements.  Policies, default parameters,
   the options supported, the style of network management and security
   requirements may vary.  This document reviews examples of such
   limited domains and emerging solutions, and develops a related
   taxonomy.  It shows the needs for a precise definition of a limited
   domain boundary and for a corresponding protocol to allow nodes to
   discover where such a boundary exists.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-limited-domains-03
https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-00.txt

[Brian E Carpenter]

Getting back to the draft under discussion:

On 2018-08-17 05:56, Tom Herbert wrote:
> The requirement that "Protocols/applications SHOULD avoid IP level
> fragmentation." already acknowledges and provides advice on the
> realities of the current state of fragmentation support in the
> network. 

Acknowledges, yes. Provides *useful* advice, no. That was my original
point. IMNSHO, useful advice would be "support PLPMTUD, and this
is how to do it." Otherwise, application developers are on their own.

> IMO, the statement that "Networks MUST support IP level
> fragmented packets." is appropriate. 

As a motto for the Internet, yes. For the present draft, not so much.

   Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-00.txt

[Brian E Carpenter]

Hi,

Earlier I said:

>>Application developers SHOULD NOT develop applications that rely on
>>IPv6 fragmentation
> 
> It isn't obvious to me that this is an algorithmic requirement. If the 
> application
> runs over TCP, how does the developer ensure that TCP will use an MSS that
> avoids the need for fragmentation? (The UDP situation is a bit clearer, but
> RFC8085 introduces considerable complexity, unless we accept that the
> Internet MTU for UDP is 576 or 1280.)

I've looked into this a bit for the UDP case, which doesn't have
the added complexity of MSS negotiation.

The only surefire way of avoiding fragmentation is to switch it
off. The recipe for doing that varies by operating system and version,
and between IPv4 and IPv6. (I have Python code that I've exercised
on Windows 7, Windows 10 and Linux. Thanks to Tom Herbert, Praveen
Balasubramanian and Nick Grifka for advice.)

Whether that automatically solves the problem depends on whether
PMTUD works, which is unpredictable. Therefore, if you want a protocol
*design* that is universal, it can't depend on PMTUD. Disabling 
fragmentation on its own is not enough. (That isn't news.)

The only universal solution therefore seems to be a fully specified
PLPMTUD solution, either built into the protocol design, or available
as a normative reference. I think that would be a better
recommendation than simply saying "don't rely on fragmentation."

IMHO RFC4821 isn't a sufficient normative reference for this.
Possibly draft-ietf-tsvwg-datagram-plpmtud will do it for UDP-based
protocols. But IMHO we need a solution for each transport protocol,
with widely available libraries.

   Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-02.txt

[Brian E Carpenter]

Tom,

Thanks for the comments. See in-line:

On 15/08/2018 12:00, Tom Herbert wrote:
> On Mon, Aug 13, 2018 at 7:07 PM, Brian E Carpenter

>>
> Hi Brian, thanks for the draft.
> 
> A couple general points:
> 
> * It's unclear to me what it means for a protocol to only work in a
> limited domain. I think there is a big difference between describing
> how a standard protocol _could_ be deployed in a limited domain for
> good effect, versus defining a standard protocol that can _only_
> operate correctly in a limited domain. 

Agreed. This is exactly why our next step is planned to be
a taxonomy of the various aspects, to try and separate
these issues.

> Most of the examples in section
> 4 are describing deployment of protocols seem to fall in the first
> category where protocol deployment might only be feasible in limited
> domain, but the definition of the protocol does not require a limited
> domain. For instance, the fact that extension headers is not
> deployable by the Internet, but may work in a limited domain, is
> happenstance on how things evolved. It was never the intent of
> extension headers to only be used in limited domains,

Correct.

> neither do I
> believe there is value in respecifying extension headers as such (I

I'd be very unlikely to do that, personally. But there might be
*semantics* that only apply within a domain. (That is how we
designed diffserv, whereas the original IPv4 TOS design was
supposed to be universal, I believe.)

> still believe problems that prevent use on the Internet should be
> fixed).

I wish that I had confidence that this could be achieved, but
there is an ongoing tension between innovation and firewall rules.

> On the other hand, something like extension header insertion
> would require a protocol to be specified to only work in a limited
> domain since that would otherwise break some fundamental requirements
> of IPv6.

Exactly.

> * If we accept that protocols can be defined for use only limited
> domains, what becomes of the priniciple of interoperability? Does this
> open up the possibility that "limited domain" could mean that any
> possible variant of a protocol is allowed per the "local policy" of
> the domain? 

That's a central question. I think the other way of looking at
it is: is it better to recognise that local semantics exist, and
figure out how to contain them, or is it better to simply
say "don't do that"?

> A limited domain would make anything possible in
> protocols. For instance, someone could decide to switch the soure and
> destination addresses in IP headers in a limited domain as a local
> policy. As long as the requirements of a limited domain is enforced
> this is completely feasible (note a limited domain could be defined by
> an island in the network having only one vendor solution). So then
> does a limited domain become a vehicle for vendors to define and
> deploy their own value-add protocol extensions without regard to
> interoperability? The open endedness of "local policy" alluded to in
> the SR protocol draft as well as some statement concerning the use of
> network slices by mobile operators that are run by a single hardware
> vendor are noteworthy.,

Absent protocol police, we can't actually stop people doing such
things, can we? So the question is how can we best deal with the
reality of local semantics without (further) damaging global
interop?

Again, thanks, this is very helpful.

   Brian

> 
> Tom

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-02.txt

[Brian E Carpenter]

Updated following comments received at IETF102.

 Forwarded Message 
Subject: I-D Action: draft-carpenter-limited-domains-02.txt
Date: Mon, 13 Aug 2018 18:42:27 -0700
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Limited Domains and Internet Protocols
Authors : Brian Carpenter
  Bing Liu
Filename: draft-carpenter-limited-domains-02.txt
Pages   : 15
Date: 2018-08-13

Abstract:
   There is a noticeable trend towards network requirements, behaviours
   and semantics that are specific to a limited region of the Internet
   and a particular set of requirements.  Policies, default parameters,
   the options supported, the style of network management and security
   requirements may vary.  This document reviews examples of such
   limited domains and emerging solutions.  It shows the needs for a
   precise definition of a limited domain boundary and for a
   corresponding protocol to allow nodes to discover where such a
   boundary exists.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-limited-domains-02
https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

[Brian E Carpenter]

On 01/08/2018 11:29, Tom Herbert wrote:
> On Tue, Jul 31, 2018 at 2:21 PM, Ole Troan  wrote:
>> Tom,
>>
>>> How is this story going to be different for IPv6? How do we ensure that 
>>> non-conformant implementation for IPv4 isn't just carried over so that 
>>> fragmentation, alternative protocols, and extension headers are viable on 
>>> the IPv6 Internet?
>>
>> I don’t think the IPv4 implementations are non-conformant.
>> (With regards to the implications of A+P on the IPv4 architecture).
>>
>> For IPv6 one would fear that the same pressures that has led to IPv4 
>> ossification applies.
>> Well, what can we do? Apart from crypto, ensure that popular applications 
>> use the features, so they cannot be shut down?
>>
> Ole,
> 
> That's the "use it or lose it" model of protocol features. TCP options
> are firmly established as a required part of TCP protocol so there is
> no way they could be obsoleted by external implemenation; IP options
> on the other were never really required for IP operation so they are
> considered expendable. The problem is that protocol features are often
> defined before the application that would use them is built, so the
> motivation to support all the features from the start isn't there.
> This seems to be the case with extension headers, since only now does
> there seem to be some serious proposals to use that functionality long
> after the mechanism was first defined and IPv6 was deployed. In
> reality, support of protocol features in the Internet is hardly ever
> binary. Plain TCP/IPv4 packets are probably the only combination of
> protocols that is guaranteed to work with probability approaching
> 100%, however pretty much anything else works with some varying of
> probability greater than 0% but less than 100% (like EH success rates
> in RFC7872). To that end, I am wondering if the idea of Happy Eyeballs
> could somehow be generalized to work with these other "non-standard"
> features.

Generalised probing might be an answer, but (especially when there
are multiple address pairs to probe) it can significantly impact
start-up latency for a session. (Some dead work on that topic is at
https://tools.ietf.org/html/draft-naderi-ipv6-probing .)

Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

[Brian E Carpenter]

> The fallback is to only hash over addresses.

Hashing over addresses+flow-label is fine too. If the flow label
is zero, it's the same thing. If the flow label is set properly,
it's a better hash.

I believe this is covered in the various relevant RFCs already
(6437, 6438 and 7098).

Regards
   Brian

On 28/07/2018 10:38, Tom Herbert wrote:
> On Fri, Jul 27, 2018 at 11:54 AM, Fernando Gont  wrote:
>> Tom,
>>
>> On 07/27/2018 07:20 PM, Tom Herbert wrote:
>> []

 For example, what happens with EHs has a lot to do with engineering:
 they could be made to work (e.g., remove performance impact), but
 devices would probably be more expensive. Folks buying gear wouldn't pay
 for something that its not used in practice, and vendors wouldn't just
 "improve" the boxes for free. -- yeah, you could argue that "hey, there
 shouldn't be penalties for EHs, since they are part of the core IPv6
 spec" -- but, while probably correct, that will not change reality.

>>> Fernando,
>>>
>>> The irony is thatxtension headers (and alternative protocols as well),
>>> including fragmentation, aren't supposed to have to "be made to work"
>>> in intermediate devices. With the exception of Hop-by-Hop options they
>>> are supposed to be ignored by design, and even in the case of
>>> Hop-by-Hop options RFC8200 relaxed the requirements so that they can
>>> be ignored. Extension headers are considered problematic only because
>>> of ad hoc assumptions made for "value add", non-standard features
>>> implemented in intermediate devices.
>>
>> Please see:
>> 
>>
>> theory != practice. And no matter how right you might be, that doesn't
>> make the theory a reality.
>>
>>
>>
 Not that I like the situation, but... I think the least we can do is to
 do a reality check wrt how things are supposed to work vs. how they
 actually work.

 For this particular case, this I-D makes that point for fragmentation: I
 I think we all agree that fragmentation is fragile -- making that point
 clear at least raises awareness of the problem, and might trigger some
 action on the topic (whether to correct the issue, or to circumvent it).

>>> Right, but I still think that we should be more clear about the root
>>> origin of problems and blunt in requesting that non-conformant
>>> implementations get fixed.
>>
>> That is certainly not going to happen. From the pov of the folks
>> operating the networks, there's nothing broken.
>>
>>
>>> For instance, as I mentioned the ECMP
>>> hasing problem with fragmentation is entriely solvable if only
>>> intermediate devices will use flow label instead of trying to find
>>> ports for a hash.
>>
>> Yes and no. There was at least a time in which the flow label wasn't set
>> at all, or even was mistaenly set (e value during 3WHS, a different
>> value afterwards). That means that you cannot really rely on it. If you
>> cannot rely on it, you need a back-up mechanism. And that mechanism is
>> inspecting the trasnport port numbers -- from that point of view,
>> there's not much sense in dong ECMP with the FL if you cannot rely on it
>> and somehow you'd have to be prepared to do it based on addresses and
>> port numbers.
> 
> The fallback is to only hash over addresses. Hashing over ports is not
> reliable and can be problematic in itself. For instance, wrt
> fragmentation, some middleboxes will use ports in the first fragment
> but fall back to hashing over addresses for rest of fragments. This
> mean the first fragment almost always takes a different path which can
> wreak havoc on down stream devices that aren't expecting that. So
> maybe it's another recommendation in this draft that middleboxes don't
> use port information from first fragment to do load balancing. This is
> another relatively easy fix.
> 
> Tom
> 
>>
>>
>>> Fixing devices to support this reasonable and should
>>> be low cost.  IMO, use of flow label for ECMP should be a strong
>>> recommendation made in this draft.
>>
>> I wouldn't mind. However, that doesn't change the fact that
>> fragmentation is fragile.
>>
>> That said, if you look at RFC7872, t all looks like anything that is EHs
>> is dropped to some extent (while not included in the RFC, I also mesured
>> IPsec, and you get similar numbers). So besides the issues that are
>> specific to fragmentation, anything that is EHs gets dropped here an
>> there. -- and ding ECMP with the FL will not change that.
>>
>> (Again: not that I'm happy with the situation... but being unhappy will
>> not change reality anyway :-) )
>>
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fg...@si6networks.com
>> PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> 

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

[Brian E Carpenter]

On 28/07/2018 08:28, Ole Troan wrote:
> 
> 
>> On 27 Jul 2018, at 22:12, Brian E Carpenter  
>> wrote:
>>
>> Fragmentation, (PL)PMTUD, extension headers, and innovative
>> L4 protocols are very possibly not viable on the open Internet.
>> At least, we can't assume that they will work on arbitrary paths.
>> Sad but apparently true.
> 
> Hasn’t this been discussed ad infinitum in the ossification work?
> If you want to generalize, nothing is guaranteed to work across an arbitrary 
> path in the Internet. 
> 
> So what? This is part of a tussle and it would be making a self fulfilling 
> prophecy for us to take all policy based filtering or other brokenness into 
> consideration when designing protocols. 

So you'd prefer that we design protocols that can't possibly work?

Yes, it's a tussle. But sometimes it's better to know you're in a
fight; it gives you a better chance of winning ;-). Anyway, we're
off topic, sorry, my fault.

   Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

[Brian E Carpenter]

On 28/07/2018 04:25, Fernando Gont wrote:
> On 07/27/2018 05:15 PM, Tom Herbert wrote:
>> On Fri, Jul 27, 2018 at 5:38 AM, Fernando Gont  wrote:


>> So has the ship sailed for out ability to ever use
>> extension headers or any protocol other than TCP (and sometimes UDP)?
> 
> It would seem that that's the case, yes.
> 

Thanks, another point we should cover in draft-carpenter-limited domains.

Fragmentation, (PL)PMTUD, extension headers, and innovative
L4 protocols are very possibly not viable on the open Internet.
At least, we can't assume that they will work on arbitrary paths.
Sad but apparently true.

   Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

[Brian E Carpenter]

+1 for adoption.

However, I am a bit concerned about this key recommendation:

>Application developers SHOULD NOT develop applications that rely on
>IPv6 fragmentation

It isn't obvious to me that this is an algorithmic requirement. If the
application runs over TCP, how does the developer ensure that TCP will
use an MSS that avoids the need for fragmentation? (The UDP situation
is a bit clearer, but RFC8085 introduces considerable complexity, unless
we accept that the Internet MTU for UDP is 576 or 1280.)

Regards
   Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

[Brian E Carpenter]

On 25/07/2018 11:46, Tom Herbert wrote:
> On Tue, Jul 24, 2018 at 3:54 PM, Templin (US), Fred L
>  wrote:
>> I have an observation that I would like to see addressed in the document. 
>> Some applications
>> (e.g., 'iperf3' and others) actually leverage IP fragmentation to achieve 
>> higher data rates than
>> are possible using smaller (but unfragmented) whole packets.
>>
>> Try it - by default, iperf3 sets an 8KB UDP packet size and allows packets 
>> to fragment across
>> paths that support only smaller MTUs. I have seen iperf3 exercise IP 
>> reassembly at line rates
>> on high-speed links, i.e., it shows that reassembly at high rates is 
>> feasible.
>>
>> We know from RFC4963 that there are dangers for reassembly at high rates, 
>> but there are
>> applications such as iperf3 that ignore the "SHOULD NOT" and leverage IP 
>> fragmentation
>> anyway. So, should the "SHOULD NOT" have an asterisk?
>>
> Fred,
> 
> My reading of the draft is that IP fragmentation is fragile on the
> open Internet and should be avoided for applications that run over the
> Internet. That doesn't mean that fragmentation should be avoided in
> all use cases. In particular, if fragmentation is used in a closed
> network with low loss and has appropriate security measures in place,
> then it can be beneficial. I suspect that describes the network that
> your're running iperf in. If this interpretation of the draft's intent
> is correct, maybe there could be some words to clarify that.

Those words are in RFC2119 already:

>> 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
>>there may exist valid reasons in particular circumstances when the
>>particular behavior is acceptable or even useful, but the full
>>implications should be understood and the case carefully weighed
>>before implementing any behavior described with this label.
   Brian

> Tom
> 
>> Thanks - Fred
>>
>>> -Original Message-
>>> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Wassim Haddad
>>> Sent: Tuesday, July 24, 2018 12:43 PM
>>> To: internet-a...@ietf.org 
>>> Cc: intarea-cha...@ietf.org
>>> Subject: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
>>>
>>> Dear all,
>>>
>>> We would like to start a WG adoption call for 
>>> draft-bonica-intarea-frag-fragile (“IP Fragmentation Considered Fragile”).
>>>
>>> https://www.ietf.org/id/draft-bonica-intarea-frag-fragile-03.txt
>>>
>>>
>>> Please indicate your preferences on the mailling list. The deadline is 
>>> August 10th.
>>>
>>>
>>> Thanks,
>>>
>>> Juan & Wassim
>>> ___
>>> Int-area mailing list
>>> Int-area@ietf.org
>>> https://www.ietf.org/mailman/listinfo/int-area
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-01.txt

[Brian E Carpenter]

Hi,

We've requested a short slot in the Intarea meeting for this draft. The
topic is quite general but we think that Intarea is a good place to
evaluate community interest.

   Brian + Sheng

 Forwarded Message 
Subject: I-D Action: draft-carpenter-limited-domains-01.txt
Date: Sat, 30 Jun 2018 15:22:32 -0700
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Limited Domains and Internet Protocols
Authors : Brian Carpenter
  Sheng Jiang
Filename: draft-carpenter-limited-domains-01.txt
Pages   : 12
Date: 2018-06-30

Abstract:
   There is a noticeable trend towards network requirements, behaviours
   and semantics that are specific to a limited region of the Internet
   and a particular set of requirements.  Policies, default parameters,
   the options supported, the style of network management and security
   requirements may vary.  This document reviews examples of such
   limited domains and emerging solutions.  It shows the needs for a
   precise definition of a limited domain boundary and for a
   corresponding protocol to allow nodes to discover where such a
   boundary exists.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-limited-domains-01
https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

[Brian E Carpenter]

On 12/05/2018 01:55, Joe Touch wrote:
> Whether 6302 makes a strong recommendation or not, it is clearly aimed at 
> policy issues.
> 
> I don’t think we need documents to explain how to implement software that 
> isn’t focused on supporting the protocols we specify.
> 
> I prefer to have 6302 deprecated so it is no longer usable as justification 
> to do otherwise (e.g., as has been done throughout this discussion).

Only by not reading the words Med quoted. I agree it would have been
better wordsmithed if it literally said "IF you examine and log packets
THEN this is how to do it." But logically, that's what it says.

   Brian

> 
> Joe
> 
>> On May 10, 2018, at 10:21 PM, mohamed.boucad...@orange.com wrote:
>>
>> Hi Joe,
>>  
>> This is a little bit subtle.
>>  
>> RFC6302 is about operating and protecting a server against abuses, 
>> denial-of-service, and all the issues discussed in rfc6269#section-13.1. 
>> 6302 does not ask a server to enable logging or not: 
>>  
>>The above recommendations apply to current logging practices.  They
>>do not require any changes in the way logging is performed; e.g.,
>>which packets are examined and logged.
>>  
>> Further, 6302 says explicitly:
>>  
>>Discussions about data-retention policies are out of scope for this
>>document. 
>>  
>> Cheers,
>> Med
>>  
>> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch
>> Envoyé : mercredi 9 mai 2018 17:02
>> À : int-area
>> Objet : Re: [Int-area] WG adoption call: Availability of Information in 
>> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
>>  
>>  
>>
>>
>>
>> From: Int-area > > on behalf of 
>> "mohamed.boucad...@orange.com " 
>> >
>> Date: Wednesday, May 9, 2018 at 7:26 AM
>> To: Juan Carlos Zuniga > >, "int-area@ietf.org 
>> " >
>> Subject: Re: [Int-area] WG adoption call: Availability of Information in 
>> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
>>  
>> Hi all, <>
>>  
>> There is no reason to revisit or deprecate RFC6302:
>> · The root technical issues as documented by intarea (RC6269) are 
>> still valid. Those issues will be experienced by more and more in the future.
>> · RFC6302 records a valid technical recommendation for servers 
>> logging IP addresses for abuse purposes.
>>  
>> I don’t think that the IETF has to mandate or preclude (IP address) logging.
>>  
>> I agree with the last sentence above, but I also think that the IETF 
>> shouldn’t be making “recommendations” in this area either (i.e., the last 
>> sentence implies to me that RFC6302 needs to be deprecated). 6302 is about 
>> identifying customers - not protocol or network diagnostics.
>>  
>> IMO:
>>  
>> - the IETF should speak to logging only when it relates to *protocol or 
>> network diagnostics*
>> - this means that the current document should not proceed
>> - this means that RFC6302 should be deprecated
>>  
>> Joe
> 
> 
> 
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

[Brian E Carpenter]

Joe,
On 10/05/2018 03:02, Joe Touch wrote:
> 
> 
>>
>> From: Int-area > > on behalf of 
>> "mohamed.boucad...@orange.com " 
>> >
>> Date: Wednesday, May 9, 2018 at 7:26 AM
>> To: Juan Carlos Zuniga > >, "int-area@ietf.org 
>> " >
>> Subject: Re: [Int-area] WG adoption call: Availability of Information in 
>> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
>>  
>> Hi all, <>
>>  
>> There is no reason to revisit or deprecate RFC6302:
>> · The root technical issues as documented by intarea (RC6269) are 
>> still valid. Those issues will be experienced by more and more in the future.
>> · RFC6302 records a valid technical recommendation for servers 
>> logging IP addresses for abuse purposes.
>>  
>> I don’t think that the IETF has to mandate or preclude (IP address) logging.
> 
> I agree with the last sentence above, but I also think that the IETF 
> shouldn’t be making “recommendations” in this area either (i.e., the last 
> sentence implies to me that RFC6302 needs to be deprecated). 6302 is about 
> identifying customers - not protocol or network diagnostics.
> 
> IMO:
> 
> - the IETF should speak to logging only when it relates to *protocol or 
> network diagnostics*

That may be a bit narrow, which is why I prefer ...relates to *operational 
requirements*. And yes, that could include requirements over which the operator 
has no control, such as regulatory requirements. It's really not the IETF's 
business *why* an operator decides to log stuff. RFC 6302 is about *how* to log 
address information.

> - this means that the current document should not proceed

A slightly different question from whether we should tackle the topic. I don't 
think the IETF would do itself any favours by tackling the topic. That doesn't 
mean the topic is unimportant, just that this is not the venue for it.

> - this means that RFC6302 should be deprecated

Why? It is about operational logging, and specifically says (end of section 2):

>> The above recommendations apply to current logging practices.  They
>> do not require any changes in the way logging is performed; e.g.,
>> which packets are examined and logged.

Regards
   Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

[Brian E Carpenter]

On 02/05/2018 04:36, Dave O'Reilly wrote:

> The IETF has a role in the governance of the Internet, 

That's news to me. I've never been completely sure what
"governance of the Internet" actually means**, but in any case
it isn't mentioned in the mission statement at
https://tools.ietf.org/html/rfc3935

Both this draft and draft-andersdotter-intarea-update-to-rfc6302
take me out of my comfort zone for IETF scope.

   Brian

** Full disclosure: my rants on this topic can be found at
https://www.cs.auckland.ac.nz/~brian/bits.html
but please let's not discuss them here.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

[Brian E Carpenter]

On 27/04/2018 21:15, Amelia Andersdotter wrote:
> On 2018-04-27 04:00, Brian E Carpenter wrote:


> i would have been slightly less annoyed had this not been the case. For
> this reason:
> 
>> This is not an area where anybody in authority gives a fig about what
>> the IETF says.
> 
> This is not reflective of my experience. The details are tedious, but
> RFC6302 in its current form, 

We need to look at one of those details. RFC6302 starts out by saying:

  "It is RECOMMENDED as best current practice that Internet-facing
   servers logging incoming IP addresses from inbound IP traffic also
   log:

   o  The source port number..."

Therefore, the whole recommendation applies *only* to servers that
happen to log incoming IP addresses. In effect, the document says:

IF you operate an Internet facing server AND you log incoming IP addresses
THEN you should also log the source port numbers (etc.).

That is a purely technical statement, because with address sharing
in use, there is no point in logging addresses without ports.

The document does *not* say:

IF you operate an Internet facing server
THEN you should log incoming IP addresses, source port numbers (etc.).

That would be a completely inappropriate thing for the IETF to say,
because it's outside our technical remit.

If draft-daveor-cgn-logging was adopted as an IETF document, it
should IMHO be subject to the same test: is it describing how to
do something correctly, if you're doing it at all? At least some
of the language in section 7 would need tuning for that. Other
parts seem OK, like "In cases where a software package has
support for logging of incoming source port,..."

Regards
   Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

[Brian E Carpenter]

(Bundling answers to two messages)
On 26/04/2018 20:40, Dave O'Reilly wrote:
...
>> IMHO we should say nothing that appears to be a recommendation
>> about the duration of logging. We can say as a factual matter that
>> logging is useful for operational purposes (fault diagnosis, abuse
>> detection, and statistical analysis) and may be legally required.
> 
> As I mentioned earlier in this discussion, logging is also useful with 
> respect to the societal need for law enforcement (which is not a euphemism 
> for anything!) and also with respect to the rights of victims of crime. 
> 
> I mention this again because these two items are always left of the list of 
> reasons why logging is useful, just like you did in your email, but they’re 
> really important ones despite their unpopularity. 

Then the wisest course for the IETF, which writes technical documents,
is probably to miss out the use cases completely, and simply say
"is useful for operational purposes and may be legally required".

On 26/04/2018 23:42, Amelia Andersdotter wrote:
...
>> We can say that the logs SHOULD be stored securely, and SHOULD NOT
>> be retained any longer than is needed for these purposes.
> 
> The risk is then that it's not practically useful for people in
> organisations that lack large legal teams.

That is somebody's problem, but the IETF writes technical specs, and
we don't do well at governance issues. If we make it our problem,
I'm not sure the discussion will ever end. Writing guidance that will
apply equally to (say) Sweden, Burkina Faso and China is probably
impossible anyway.

...
> (I know my affiliation is an CSO for IETF purposes, but
> plenty of CSOs don't work in tech standards groups at all)

To be a little picky, your affiliation doesn't matter here...
we all participate as individuals in the IETF. To be clear,
you raise important issues - for me the question is whether
the IETF is competent to solve them, beyond the narrow technical
aspect.

Regards
Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

[Brian E Carpenter]

On 26/04/2018 04:07, Amelia Andersdotter wrote:
> On 2018-04-25 14:42, mohamed.boucad...@orange.com wrote:
>> You could have two different objections to the draft:
>>
>> 1. The IETF does not, in general, recommend grace periods or time
>> periods for logging, caching, etc. That's just wrong - I find loads of
>> examples in old and new RFCs of recommended time-periods for data
>> storage by googling.
>> [Med] AFAIK, there is no such IETF reco for address sharing specifications. 
> 
> The IETF has made recommendations against a backdrop of highlighted
> regulatory requirements mandating storage of data (for 6-12 months), cf
> RFC7768, RFC6269. So the time-limits are there, just not decided on
> technical merits, but by reference to legal merits.

We can recommend what we like, but the fact of life is that products will
be designed to support the most stringent regulatory requirement in the
world market, and if there are conflicting requirements in different
jurisdictions there will be corresponding configuration options in the
products. So even if we put privacy-protecting SHOULDs in our RFCs,
the regulators decide what actually happens. I'm not against putting
those SHOULDs but I try to be realistic about their impact.

RFC6269 is Informational, describing issues. So it doesn't matter
what it says, really. It doesn't recommend anything. RFC7768 is
also Informational, only offers "A Suggested Solution", and is not
an IETF document anyway. So again, it doesn't matter what it says.

IMHO we should say nothing that appears to be a recommendation
about the duration of logging. We can say as a factual matter that
logging is useful for operational purposes (fault diagnosis, abuse
detection, and statistical analysis) and may be legally required.
We can say that the logs SHOULD be stored securely, and SHOULD NOT
be retained any longer than is needed for these purposes.

   Brian
 
> But the examples I mentioned are for other types of identifiers that are
> logged, cached or stored. RFC2308 Section 7.1 and 7.2, for example.
> RFC5988 section 6.3. In general, the IETF could decide to recommend data
> minimization in terms of storage duration, was what I meant, and it
> wouldn't be a complete break from tradition.
> 
>>> 2. The time-period as suggested is wrong. For instance, as Povl
>>> proposed, 3 days is reasonable if it's just about shifting the log from
>>> the internet-facing server as such to somewhere else, and for storing
>>> logs at end-destination a longer period of time is necessary.
>>>
>>> I think you're aiming for objection 1). I don't see the historical
>>> precedent for this assertion, and it seems to be rather about what the
>>> IETF would feel like. I'm open for discussion on objection 2).
>> [Med] Hmm. Please check 
>> https://mailarchive.ietf.org/arch/msg/behave/GzY46_zyxVDeKv10nGzGWM8FA34 
>>
> 
> Not sure I see the relevance? Neither RFC6269 nor RFC7768 should have
> been adopted by workgroups or become RFCs if that 2011 e-mail had
> established an IETF praxis.
> 
> best regards,
> 
> Amelia
> 
>>> best,
>>>
>>> A
>>>
 Cheers,

 Med



 *De :*Povl H. Pedersen [mailto:p...@my.terminal.dk]
 *Envoyé :* mercredi 25 avril 2018 13:16
 *À :* BOUCADAIR Mohamed IMT/OLN
 *Cc :* int-a...@ietfa.amsl.com
 *Objet :* Re: [Int-area] WG adoption call: Availability of Information
 in Criminal Investigations Involving Large-Scale IP Address Sharing
 Technologies



 I would keep full IP address + port info in my firewall log. Separate
 from the webserver log. This to help the webguys not abusing collected
 data.

 Having talked to the webguys, they use the logfiles in daily
 operations, and they see them as necesary to provide continous
 delivery of the services to the end user.That is another obligation we
 have.
 Our legal department actually suggested we keep logs for 5 years, as
 some data must be kept that long.

 The big privacy issue here is more about abuse and losing the data
 (move them away from the internet facing server within 3 days would be
 a good recommendation). This must be controlled by internal company
 rules. Not this RFC that says we must cripple data after 3 days. And 3
 days is a stupid limit if there is a longer weekened/holidays etc.
 Easter is an example, Thursday to monday are non-working days. That is
 5 days + the extra. So the 3 days should be 6 days without even
 accounting for holidays.



>>> --
>>> Amelia Andersdotter
>>> Technical Consultant, Digital Programme
>>>
>>> ARTICLE19
>>> www.article19.org
>>>
>>> PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55
>>>
>>> ___
>>> Int-area mailing list
>>> Int-area@ietf.org
>>> https://www.ietf.org/mailman/listinfo/int-area
> 
> 

___
Int-area mailing list
Int-area@ietf.org

Re: [Int-area] draft-andersdotter (was RE: WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

[Brian E Carpenter]

On 25/04/2018 11:37, Ted Lemon wrote:
> Brian, does the server *have* to collect everything?

Clearly not, but operations people are much more likely to apply a "log
everything we can store" approach than to be selective in advance. I think
it's privacy law, not IETF BCPs, that will make them think more carefully.

http://www.waitrose.com/privacynotice is worth a read, I found. It makes
IP addresses look very uninteresting.

Brian

> 
> On Tue, Apr 24, 2018, 18:26 Brian E Carpenter <brian.e.carpen...@gmail.com>
> wrote:
> 
>> On 24/04/2018 18:08, Amelia Andersdotter wrote:
>>> Dear Mohamed,
>>>
>>> See below:
>>>
>>> On 2018-04-24 07:25, mohamed.boucad...@orange.com wrote:
>>>>
>>>> [Med] I don't have a problem with the general intent of your text, my
>> concern is that you link those explicitly with RFC6302 which is misleading.
>> RFC6302 has a very clear focus: address sharing.
>>>>
>>>> [Med] But how this is related to RFC6302 context?
>>>
>>> RFC6302 is hopelessly out of date. It was specifically justified by a
>>> regulatory framework which no longer exists(!) and it takes into account
>>> none of the privacy guidances given by RFC6973.
>>
>> I can't find any reference to regulatory matters in RFC 6302,
>> but I did find this:
>>   "In the absence of the source port number and accurate timestamp
>>information, operators deploying any address sharing techniques will
>>not be able to identify unambiguously customers when dealing with
>>abuse or public safety queries."
>> Has that changed since 2011?
>>
>> RFC6973 adds this:
>>   "When requiring or recommending that information
>>about initiators or their communications be stored or logged by end
>>systems (see, e.g., RFC 6302 [RFC6302]), it is important to recognize
>>the potential for that information to be compromised and for that
>>potential to be weighed against the benefits of data storage."
>> Indeed. But since that's a general requirement, not specific to port
>> logging, what is obsolete in RFC6302 itself? It's what happens to the data
>> *after* it's been collected that matters, and that affects everything
>> the server collects, not just addr+port.
>>
>> Regards
>>Brian
>>
>>> If we mean to say the
>>> privacy guidelines of RFC6973 should not be applied specifically in our
>>> recommendations for logging to internet-facing servers, then fine. If,
>>> however, we believe privacy guidelines apply also when we make
>>> recommendations to internet-facing servers (as we have done), then
>>> RFC6302 needs updating.
>>>
>>> I think this is the primary thing to establish. I'll provide more
>>> comments later.
>>>
>>> best,
>>>
>>> A
>>>
>>>
>>
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
>>
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

[Brian E Carpenter]

On 25/04/2018 01:25, Ted Lemon wrote:
> On Apr 24, 2018, at 9:11 AM,  
>  wrote:
>> What sort of trade-offs can be added to Dave’s document? Do you have in mind 
>> something like:
>> (1)
>> -Warranting that logging may be misused for tracking users?  
>> -Logging information can be used for profiling users?
>> -Not logging is also an option?
> 
> I don't think Dave's document is a good starting point.   Amelia (I think it 
> was Amelia) already pointed out a number of things to talk about: for 
> example, if you are going to log source ports, it should be possible to log 
> them only when doing so is necessary, and not log them at other times.

I have trouble with that. When a user complains that "my transaction at 23:59 
UTC
yesterday failed", it's too late to switch on logging. So I think in practice, 
logging
for problem debugging needs to be switched on 24x7. Similarly for abuse 
detection,
since you can't predict when abuse will happen. I don't think there's a get out
of jail card here. The problem is what happens to the logged data later, and 
that
is a regulatory issue that the IETF can do absolutely, utterly nothing about.

Brian

>   This is a meaningful technical point that would have clear implications in 
> the code that got written.   It's not just a platitude to put in the privacy 
> considerations section.   That's what I have in mind too.
> 
> So yes, of course we should say "there are problems with logging source 
> ports, and these are some examples of the problems doing so can cause."
> 
> TBH, if I were an open source implementor, I would just ignore any advice 
> about logging source ports, so if you want the document to have any relevance 
> in that space, you have to give such people a reason for doing it and a basis 
> for doing as little harm as possible.
> 
> 
> 
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

[Brian E Carpenter]

On 25/04/2018 00:49, Dave O'Reilly wrote:
> Amelia,
> 
> I have read this draft now and, once again, it seems there has been no 
> consideration of the implications for law enforcement of these 
> recommendations. A further example of the "privacy is good, more privacy is 
> better" philosophy. 
> 
> I also reviewed RFC6973 and the exact same problem is present there. The 
> privacy threats highlighted in RFC6973 are reasonable from a privacy 
> advocate’s perspective and worthy of consideration, and the mitigants listed 
> also make sense in the context of the listed threats. However, to intimate 
> that the representations of RFC6973 are the only possible perspective, or in 
> some objective sense the “right” perspective, or indeed in any way a complete 
> perspective, misses out important societal issues such as those that are 
> being discussed in this thread.
> 
> The considerations that appear to be foremost in RFC6973 are the issues 
> relating to the collection and use of personal data for commercial purposes 
> and the impact of data breaches

These days we would add "political purposes", and that is interesting because
it has both societal and possible criminal implications. But those issues are
much wider than IP addresses and ports. 

> - the crime attribution characteristics are hardly considered at all. Only 
> surveillance is mentioned and this category, crime attribution per se is not 
> considered at all.

For a reason. A tool that can be used by the authorities for tracing crime to 
its
source can be used by authorities for tracing political activity to its source,
which in many countries is considered to be abuse of power. And if the tool 
itself
is vulnerable, it can be mis-used by non-government actors for bad purposes.
This is the argument behind RFC 2804 of course, and I don't see this discussion
as anything different in principle.

RFC 6302 is a bit different. Server logs are sometimes essential for problem
debugging, rather than for penetrating privacy.

   Brian

> It is also sort of implied that surveillance is always a bad thing (it is, 
> after all, listed in the privacy threats section with no consideration of if, 
> or why, there might be a legitimate use for surveillance, subject to 
> appropriate legal safeguards of course) - another point that should be 
> debated and not automatically accepted.
> 
> The only trade-offs that are suggested for consideration are (ref. section 
> 4.a)  "privacy and usability, privacy and efficiency, privacy and 
> implementability, or privacy and other design goals”. What about, for 
> example, privacy and potential for misuse, privacy and potential for 
> concealing criminal activity, etc. etc.?
> 
> Coming back to the Internet Draft for a moment, there are other points that I 
> could raise but I only want to draw out one rather glaring misrepresentation 
> for now:
> 
> "Earlier recommendations contained in [RFC6302] relied heavily on 
> observations made in Section 12 of [RFC6269] that regulatory requirements 
> could imply a broad obligation to log identifiers.”
> 
> RFC6302 has nothing to do with regulatory requirements to log anything. 
> RFC6302 relates to recommendations that Internet-facing servers log source 
> port information alongside IP address. The overwhelming majority of 
> Internet-facing servers are subject to no form of regulation at all. The fact 
> that RFC6269 highlights a regulatory requirement to maintain subscriber 
> identity, and the subsequent striking down of the data retention directive, 
> is immaterial to the substance of RFC6302 and RFC6302 does not rely on it in 
> any way. Attempting to throw out the existing recommendations in RFC6302 
> because of the ECJ ruling on data retention directive is disingenuous. 
> 
> daveor
> 
>> On 23 Apr 2018, at 09:10, Amelia Andersdotter  wrote:
>>
>> I've tabled a similar draft but with a different scope. Happy to discuss
>> with members on the list:
>>
>> https://datatracker.ietf.org/doc/draft-andersdotter-intarea-update-to-rfc6302/
>>
>> -- 
>>
>> Amelia Andersdotter
>> Technical Consultant, Digital Programme
>>
>> ARTICLE19
>> www.article19.org
>>
>> PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55
>>
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area