Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

[Joel Jaeggli]

On 8/24/18 8:24 PM, Toerless Eckert wrote:
> On Fri, Aug 03, 2018 at 09:48:25AM +0200, Mikael Abrahamsson wrote:
>> I've kept saying "Networks must support ip fragmentation properly.
> Why ? Wheren't you also saying that you've got (like probably many
> else on this thread) all the experience that only TCP MSS gets you
> working connectivity in many case (like hotels) ?
>
> IMHO, we (network layer) should accept defeat on network layer 
> fragmentation and agree that we should make it easier for the
> transport layer to resolve the problem.
>
> Aka: I would lvoe to see a new ICMPv4/ICMPv6 reply and/or PTB reply option
> indicating "Fragmented Packets Not Permitted". Any network device which
> for whatever reason does not like Fragemnts would simply drop
> fragmented packets and send this as a reply. Allows then the
> transport layer to automatically use packetization  (such as TCP MSS) 
> to get packets through. 

It's actually not that useful if it's an icmp message. because it's
going to fail in many cases where it has to be hashed to a destination.
just  like non-initial fragements do...

4821 gets you there with tcp.

>
> Of course. Will take a decade to get ubiquitously deployed, but
> neither IPv4 nor IPv6 will go away, only the problems with fragmentation
> will become worse and work if we do not have an exit strategy like this.
It's not going to be ubiquitously deployed because it's not going to work.
> If we don't try an exit strategy like this, we will just get what
> Joe said, the complete segmentation of the Internet with more and
> more L4 or even higher layer proxies.
>
> Btw: +1 for adopting the doc as a WG item, but primarily because everything
> before section 7 is on a way to become a good read of reality. Section
> 7 recommendations is only a faith based exercise (praying) as long as it 
> tries to
> get the job done primarily by appealing to application developers.
>
> Cheers
> Toerless
>
>
>
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>


pEpkey.asc
Description: application/pgp-keys
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] review of draft-perkins-intarea-multicast-ieee802-03 draft-mcbride-mboned-wifi-mcast-problem-statement-01

[joel jaeggli]

Greetings,

I have chosen to review both of these documents at this time as they
appear to me to be attempts to address the same problem space from the
vantage point of slightly different but overlapping communities
(evidenced by the authors) both of which have a vested interest in IP
multicast operation on ieee 802.xx wireless networks. This review is
seperated into the observations common to both followed by (limited)
commentary on each document.

While both documents address the challenges of arp / ND and aperiodic
multicast transmission,
draft-mcbride-mboned-wifi-mcast-problem-statement-01 has more focus on
application use of multicast above and beyond basic
subnet/adjacency/resource discovery applications.

draft-perkins-intarea-multicast-ieee802-03 takes a more technical and
nuanced look at the underlying 802.xx implementation of
multicast/broadcast packet transmission. It is oddly specific in some
areas to experiences gleaned from the IETF network, which while it may
be a product of our experience, is  by no means a unique environment,
and these challenges are to a great degree common or in fact worse  in
other wireless environments (where there might be more low powered
devices, less spectrum or radio coordination, a diversity of management
domains and so on.

it's  not clear to me from the outset what the audience for an
eventually published document might be.

Advice to implementors?

Feedback to the IEEE?

Operational advice?

Go from problem statment towards work on conclusions?

draft-perkins-intarea-multicast-ieee802-03  is the slightly more mature
document of the two,  I don't think that there is much justification for
advancing both given that they have fairly high overlap without being
complimentary, so I would encourage consolidation and coordination
between the int interests and those of the mbone/multicast community
towards something that is more than the union of the two.

>From my vantage-point the best outcome is one where the IETF provides
advice to vendors (becaue there are implementation specific tweaks and
optimation that can make many situations better) an the IEEE that
results in the employment of multicast being less disruptive and costly
and potentially to devices on wireless lans. work on ietf protocols
associated with arp/nd resource discovery to make them generally less
costly on the wire and more sensitive to power / cpu usage is a
desirable property as well pariticularly  of there are situations where
they can be avoided entirely (for example not having to defend addresses
via DAD because of something like
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13).


Some comments specific to each document

- draft-perkins-intarea-multicast-ieee802-03 -

3.1.2.  Lower Data Rate

this rate might be as low as 6 Mbps, when
some unicast links in the same cell can be operating at rates up to
600 Mbps.

In fact backward compatibility and  multi-stream implementations mean
that the maximum unicast rates are currently up to a few Gb/s so there
can be a more than 3 order of magnitude difference in the transmission
rate from the basic rates to optimal unicast forwarding. some techinues
employed to increase spectral efficiency such a spatial multiplexing in
mimo systems are literally unavailable with more then one intended
reciever so it's not simply the case that nominal transmission rates
available are limited by backwards compatibility.

3.2.2. IPv6 issues

Respecting some of the cost of multicast on wireless networks these are
not strictly wireless problems reductions in the amount of signaling
required is better for the control-planes of routers, and for all hosts
ultimately, whether that is unicast RAs, prefix per host, or simply rate
limits on layer 2 learning e.g. https://tools.ietf.org/html/rfc6583
problems. 3.2.4 and 3.2.2 therefore are very much problems that extend
beyond the wireless domain.

Specifically with 3.2.4 the arp problem also applies to ND, in both
cases non-standard counter-measures (arp sponging unlearned entries as
in 5.1 for v4) various forms of off-net vs on-net driven ND suppression.

On a wired network, there is not a huge difference amongst unicast,
multicast and broadcast traffic;

Inadvertent flooded traffic or high amounts of ethernet multicast on
wired networks can be quite a bit less costly due to nic filtering, then
in cases where devices have to wake up effectively to process packets.
also the fact that these networks tend to be switched futher reduces
impact (there is effectively no collision / scheduling problem until you
get to extremely high port utilization)

4.3

not clear how this directly impacts multicast / except that a unicast
optimization ight seperately send to different STAs at different times.
optimization around long DTIM intervals to allow clients to sleep longer
clearly has impacts on performance, convergence 

Re: [Int-area] Fw: Continuing IPv10 I-D discussion.

[joel jaeggli]

On 3/31/17 09:24, Khaled Omar wrote:
>> "all OSs will be updated to support IPv10 which is an easy
>> task"...
>>> What makes you think it is ever an easy task to get all OSes to
>>> uniformly support anything? Please provide an implementation so
>>> we can evaluate the prospects.
> 
> For the 2nd time:
> 
> "I shouldn't list all devices that need to support IPv10, simply,
> anything will process a L3 packet, should understand that the IPv10
> packet can contain a mixture of IPv4 and IPv6 addresses."

Assuming for the sake of argument that I am designing a forwarding asic.
When I pass over the ethertype code in the frame, I decide what
forwarding lookup path I am going to exercise the ipv4 or ipv6 one. If i
choose door number 1 the ipv4 path  due to 0x0800  and destination mac
being me the byte offset for the source is 12 and the destination is 4
bytes later at byte offset 16. if these fields are of variable length
then a 16 byte source address overflows the fixed offset  where the
destination  is supposed and the destination address is lost to me
because it's where optional fields might otherwise be.

If I choose the v6 path due to 0x86DD then I find the source address
address at byte 8 and the destination beginning at byte 24 there, there
are of course several ways to represent a an ipv4 mapped address within
ipv6, none of them are of any use to an native ipv4 speaker.

The fields in the packet header are not self-described (they could be,
packet header could be json for example  but in the interest of
performance they were / are not), therefore  in the interestes of
clarity a new ethertype for ipv10 with either a fixed size source and
destination address size  or a whay of specifying the offset, and a bit
or multiple bit field for the AF of both the source and destination
would greatly facilitate the design of a parser that would be able to
handle the selection of AF for lookup. at the point you've go an
entirely new header which is not compatible with either V4 or V6
parsers. in practical terms that means the useful deployment of a v10
compatible parser at internet scale is approximately as hard as
deploying the the v6 compatible parser would be if we started now
instead of in 1995 when the internet was much smaller.

joel

> 
> -Original Message- From: Tom Herbert
> [mailto:t...@herbertland.com] Sent: Friday, March 31, 2017 4:19 PM To:
> Khaled Omar Cc: Bless, Roland (TM); int-area@ietf.org Subject: Re:
> [Int-area] Fw: Continuing IPv10 I-D discussion.
> 
> On Fri, Mar 31, 2017 at 5:13 AM, Khaled Omar
>  wrote:
>>> As has been stated again and again. Your proposal would have been
>>> interesting if it was presented in 1995, or perhaps even in
>>> 2000.
>> 
>> FYI, IPv10 will allow IPv4 to communicate to IPv6 and vice versa,
>> how can it be interesting if it was presented before IPv6 was even
>> developed !
>> 
>>> Most likely, even if Microsoft could be convinced that IPv10 is
>>> something they need to support, this would only happen in Windows
>>> 10. Then we have the rest of the ecosystem with access routers,
>>> load balancers, SAVI-functionality for BCP38 compliance in access
>>> devices, core routers etc.
>> 
>> Please, let's not be against ourselves, all OSs will be updated to
>> support IPv10 which is an easy task, OSs will not require support
>> for a new IP version like IPv6, they will just be enabled to
>> support the encapsulation of both version on the same L3 packet
>> header.
> 
> "all OSs will be updated to support IPv10 which is an easy task"... 
> What makes you think it is ever an easy task to get all OSes to
> uniformly support anything? Please provide an implementation so we
> can evaluate the prospects.
> 
> Tom
> 
>> 
>> Also, networking devices will be upgraded to understand the new
>> IPv10 packet, I said earlier I don't mind If the process will take
>> some time but we should eventually reach consensus, I shouldn't
>> list all devices that need to support IPv10, simply, anything will
>> process a L3 packet, should understand that the IPv10 packet can
>> contain a mixture of IPv4 and IPv6 addresses.
>> 
>> 
>> -Original Message- From: Int-area
>> [mailto:int-area-boun...@ietf.org] On Behalf Of Bless, Roland (TM) 
>> Sent: Friday, March 31, 2017 9:51 AM To: Mikael Abrahamsson Cc:
>> int-area Subject: Re: [Int-area] Fw: Continuing IPv10 I-D
>> discussion.
>> 
>> Hi Mikael,
>> 
>> thanks for clarifying again, everything +1!
>> 
>> Regards, Roland
>> 
>> Am 31.03.2017 um 08:17 schrieb Mikael Abrahamsson:
>>> On Thu, 30 Mar 2017, Khaled Omar wrote:
>>> 
 You can read the IPv10 I-D again and all your concerns will be
  obvious, I don't mind if you have already a series of new
 questions that will add a new value to the discussion but the
 time to deploy IPv10 is an important factor.
 
 We need consensus after understanding how IPv10 works and how
 it will be deployed.
>>> 
>>> As has been stated again and 

Re: [Int-area] Fw: Continuing IPv10 I-D discussion.

[joel jaeggli]

On 3/31/17 11:05, Khaled Omar wrote:
>> I don¹t see any evidence that you are gaining consensus. Jen¹s
>> suggestion was very good: develop a stack and get some deployment
>> experience to show it can work.
> 
> There are many people who likes IPv10 and support it, also I'm not a
> software developer who works for a company developing an OS, if you
> don't believe that this idea works, you have to try it by yourself
> and get back to me with the result and what was your problem, maybe
> you are not good in writing codes or whatever.

Ad Hominem arguments are not acceptable basis for discource here or
elsewhere in the IETF.

https://tools.ietf.org/html/rfc7154

Thanks
joel



signature.asc
Description: OpenPGP digital signature
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03

[joel jaeggli]

On 5/24/16 6:48 AM, Joe Touch wrote:

> While this is a nice goal, it's not viable. In order to provide a viable
> IPv6 tunnel, the payload MUST transit IPv6 payloads of at least 1280
> bytes.However, there's no reason to assume that the UDP/IPv6 tunnel can
> support 1280 + UDP + IPv6. So you have only one choice - you can deploy
> these tunnels only where you can guarantee paths that support 1280+8+40
> byte payloads over the tunnel path. However, there's no way to ensure
> that solely by assuming IPv6 along that path.
> 
> I.e., you MUST support source fragmentation at the ingress at the outer
> IPv6 layer (because UDP doesn't have support for fragmentation and
> reassembly). If you make this requirement, you can handle IPv6 over the
> tunnel.

Yeah I don't support it for this reason. getting IP fragments back
together in the same place a reassembled is hard is in some cases
especially when you hash. (see frag drop) given alternatives that better
address such situations it seems hard to justify.

> IPv4 will work over a UDP/IPv6 tunnel fairly easily, even assuming the
> common typical IPv4 MTU (576, even though that's really the reassembled
> MTU, not the path MTU).
> 
> IPv4 over IPv4 is much more difficult, and not only requires
> fragmentation at the outer packet but also additional reassembly
> requirements at the egress above and beyond the IPv4 minimums.
> 
>>
>>
>> - signalling support (e.g., to test whether a tunnel is up or
>>
>> to measure MTUs)
>>
>>  
>>
>> [Xiaohu] It said in the draft that
>>
>> “it is strongly RECOMMENDED that Path MTU Discovery [RFC1191
>> ] [RFC1981
>> ]
>>
>>is used to prevent or minimize fragmentation.”
>>
>>  
>>
>>  
>>
>> - support for robust ID fields (related to fragmentation,
>>
>> e.g., to overcome the limits of IPv4 ID as per RFC 6864)
>>
>> in other words, the PMTUD signaling is recommended to be supported.
>>
> 
> PMTUD is a recipe for black-holing. PLPMTUD is preferred for many reasons.
> 
> However, PLPMTUD only ensures proper discovery of the tunnel MTU. It
> does not describe how the ICMPs inside the tunnel relate to those that
> are generated by the ingress.
> 
> Again, for all of these, see draft-ietf-intarea-tunnels
> 
> Joe
> 
>>  
>>
>> [Xiaohu] Is it enough to add a sentence like “to overcome the
>> limits of IPv4 ID as per RFC 6864 when performing fragmentation on
>> E-IP IPv4 packets, the specifications as described in RFC6864 MUST
>> be followed.”?
>>
>>  
>>
>> Best regards,
>>
>> Xiaohu
>>
>>  
>>
>>  
>>
>> I’m wondering whether those issues are specific to IP-in-UDP or
>> not. In other words, are those issue also applicable to other
>> X-in-UDP approaches (where X could be LISP, TRILL, VXLAN,
>> VXLAN-GPE, GENEVE, GUE, NSH or MPLS)?
>>
>>
>> That set of issues applies to all IP-in-(xlist), where xlist includes
>> IP again. The issue is what IP expects and what the tunnel exports.
>>
>> The other items I pointed out are specific to transport-in-UDP or this
>> specific approach.
>>
>> Joe
>>
> 
> 
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> 




signature.asc
Description: OpenPGP digital signature
___
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-welzl-icmp-text-middleboxes-00.txt

[joel jaeggli]

ignoring for a second the question of information leakage which is
apparently intentional in this case; an icmp message is unlikley to hash
onto the same path that the offending/failed flow would have been on in
many networks. While I can think perhaps more illustrative examples of
uses for a free form txt field (DMARC for example). the notion that
freeform txt messages with no source authetication should end up in a
ticketing system in an actionable fashion seems extrodinarily unlikely.


On 6/29/15 3:35 PM, Michael Welzl wrote:
 Dear all,
 
 We just posted the draft below. Not knowing which other group would fit, 
 we're sending it here. We're really transport people and at least I am newbie 
 to this group...  very curious to hear your thoughts:
 - completely idiotic?
 - exactly what the world has been waiting for?
 
 ... I guess it can only be one of the two above  :-) If the chairs think 
 that this makes sense to discuss in Prague, we'll be there, and I'd be happy 
 to do a supershort presentation, but let us first hear what you think. It's a 
 short and easy read, we promise that!  :-)
 
 Thanks!
 Michael  Janjie
 
 
 Begin forwarded message:

 Resent-From: mich...@ifi.uio.no
 From: internet-dra...@ietf.org
 To: Jianjie You youjian...@huawei.com, Michael Welzl mich...@ifi.uio.no, 
 Jianjie You youjian...@huawei.com, Michael Welzl mich...@ifi.uio.no
 Subject: New Version Notification for 
 draft-welzl-icmp-text-middleboxes-00.txt
 Date: 30. juni 2015 kl. 00.24.23 CEST


 A new version of I-D, draft-welzl-icmp-text-middleboxes-00.txt
 has been successfully submitted by Michael Welzl and posted to the
 IETF repository.

 Name:draft-welzl-icmp-text-middleboxes
 Revision:00
 Title:   Text messaging to middlebox administrators using ICMP
 Document date:   2015-06-30
 Group:   Individual Submission
 Pages:   6
 URL:
 https://www.ietf.org/internet-drafts/draft-welzl-icmp-text-middleboxes-00.txt
 Status: 
 https://datatracker.ietf.org/doc/draft-welzl-icmp-text-middleboxes/
 Htmlized:   
 https://tools.ietf.org/html/draft-welzl-icmp-text-middleboxes-00


 Abstract:
   This document describes the use of an ICMP message to send text
   messages to on-path middleboxes from the endpoints.  The text message
   is sent towards a destination but meant to be read by administrators
   of middleboxes along the path to the destination.  The goal is to
   improve the user's experience with simple middlebox cooperation.





 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.

 The IETF Secretariat

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




signature.asc
Description: OpenPGP digital signature
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

[joel jaeggli]

Greetings int-area and hiaps-mailing-list folks,

I realize that this is midweek at the IETF, however this question is not
far from several discussions I've had this week.

I have been asked to consider AD sponsoring
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

In the process of  considering doing so I'd like to get some input with
respect to:

A. The appetite for pursuing some or any of this work in existing
working groups, and in particular within the INT area.

B. A consensus basis for moving beyond RFC 6269 into active work in this
area.

C. How we address concerns raised by the IETF community expressed
through  draft-farrell-perpass-attack when evaluating scenarios and
beginning to address requirements and solution-space.

Obviously these are complex questions and I do not expect that we will
arrive at answers easily nor does work on this or other drafts depend on
answering them, however it's part of the dialog.

Thanks
joel



signature.asc
Description: OpenPGP digital signature
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02

[joel jaeggli]

On 12/20/12 5:38 PM, Liubing (Leo) wrote:

I'm in favor of it. It's a good use case of flow label for L3/4 load balancing
RFC 6437 did not go nearly far enough in my opinion make the flow label 
suitable for this application.


The fact of the matter is if I attempted to use the flow label today as 
part of a load balancing scheme it would provide zero additional 
entropy, and what's more I still have to look at the upper layer header.


Furthermore the document proposes the use of flow label across muliple 
flows as a common session key across multiple flows which I personally 
feel is inconsistent with the notion of a flow, is certainly embedding 
upper layer (notionally above the l4 header) session information in the 
layer-3  header and suffers from the exposures described in section 6 of 
6437 and making no attempt to ameliorate them.



Thanks

B.R.
Bing


-Original Message-
From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On
Behalf Of Suresh Krishnan
Sent: Tuesday, December 18, 2012 8:46 PM
To: Internet Area
Cc: Julien Laganier; Ralph Droms
Subject: [Int-area] Call for adoption of
draft-carpenter-flow-label-balancing-02

Hi all,
   This draft has been presented at intarea face to face meetings and has
received a bit of discussion. It has been difficult to gauge whether the
wg is interested in this work or not. This call is being initiated to
determine whether there is WG consensus towards adoption of
draft-carpenter-flow-label-balancing-02 as an intarea WG draft. Please
state whether or not you're in favor of the adoption by replying to this
email. If you are not in favor, please also state your objections in
your response. This adoption call will complete on 2013-01-04.

Regards
Suresh  Julien


___
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-shen-traceroute-ping-ext-03.txt

[Joel jaeggli]

On 1/3/12 11:33 , Carlos Pignataro wrote:
 Joel, Jared,
 
 On 12/27/2011 8:03 PM, Jared Mauch wrote:
 Joel,

 On Dec 24, 2011, at 1:28 PM, Joel jaeggli wrote:

 So, something targeted through the forwarding plane that filters up to
 the control plane will be filtered first either by source address or
 passed through a rate limiter or both because those are the protections
 we have that actually scale. Authentication increases the vulnerability
 to some kinds of abuse rather that decreasing it.


 Thanks.  I think I mentioned this in another message, but captures an 
 important
 concern about the network elements being managed.  Implementation details 
 matter.

 
 Yes, this is an inband packet flowing through the forwarding plane, that
 upon exception needs processing. What you describe is the existing
 traceroute mechanism, as well as other protocols, some widely
 operationally deployed (including MPLS Ping in RFC 4379 with the
 complexity and computational expense of a dsmap hashing, RAO in RFC 5971
 and RSVP, etc).

The existing icmp exception generation mechanism can and is distributed
to line card cpus in some router platforms. there's quantitative
differences associated with handling those requests in a distributed
fashion and punting them up to the control plane because you need more
information than is generally available on a linecard in order to
process the request. that applies both to the contents and the
authentication mechanism.

 I agree with your point that authentication increases the surface area
 for abuse in some conditions. I think that one approach here is to
 describe, in an applicability statement, in which cases an
 authentication is useful versus in which ones it is potentially harmful.
 Would you agree?

I think that would be acceptable.

 Also, please note that the authentication mechanism is not the most
 important part of draft-shen-traceroute-ping-ext.
 
 Thanks,
 
 -- Carlos.
 
 - Jared


 

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

Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt

[Joel jaeggli]

On 12/21/11 15:02 , Naiming Shen wrote:
 
 Hi Jared,
 
 I completely agree. That is one of the reasons this draft has the 
 authentication object also defined.
 The source of the query has to be a trusted host in order to reveal 
 network/enterprise private
 information from the responder.

So, something targeted through the forwarding plane that filters up to
the control plane will be filtered first either by source address or
passed through a rate limiter or both because those are the protections
we have that actually scale. Authentication increases the vulnerability
to some kinds of abuse rather that decreasing it.

 thanks.
 - Naiming
 
 On Dec 21, 2011, at 2:57 PM, Jared Mauch wrote:
 
 The idea that network operators will allow someone outside their 
 administrative control have this level of visibility is interesting but 
 unworkable. 

 Those who wish to reveal this data can do so via other means such as public 
 looking glasses and graphs. The major networks will not reveal this. 

 Jared Mauch

 On Dec 20, 2011, at 5:41 PM, Naiming Shen naim...@cisco.com wrote:


 Hi Wes,

 Sure you can certainly use tools such as SNMP to query on those info,
 the same thing can be said using SNMP to query on MPLS and interface
 related information also. Although this is not only for one host, this is 
 generally
 used by Traceroute application when traverse a list of hosts/routers.

 thanks.
 - Naiming

 On Dec 20, 2011, at 1:52 PM, George, Wes wrote:

 From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On
 Behalf Of Naiming Shen
 Sent: Tuesday, December 20, 2011 3:23 PM

 I would
 think it's useful to return the icmp response like: i'm the VM for
 location
 tracking service with SQL database, CPU 80% busy


 [WEG] No, absolutely not. We have multiple protocols to handle this 
 information already, with significantly better granularity of information 
 as well as access control permissions (who is allowed to query/receive 
 this information), most notably SNMP. There is *zero* reason to try to 
 bolt this sort of information into an ICMP datagram.
 Please stick to information that is not available via alternate means if 
 you are trying to justify its existence.

 Thanks
 Wes George

 This E-mail and any of its attachments may contain Time Warner Cable 
 proprietary information, which is privileged, confidential, or subject to 
 copyright belonging to Time Warner Cable. This E-mail is intended solely 
 for the use of the individual or entity to which it is addressed. If you 
 are not the intended recipient of this E-mail, you are hereby notified 
 that any dissemination, distribution, copying, or action taken in relation 
 to the contents of and attachments to this E-mail is strictly prohibited 
 and may be unlawful. If you have received this E-mail in error, please 
 notify the sender immediately and permanently delete the original and any 
 copy of this E-mail and any printout.

 ___
 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] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting

[Joel jaeggli]

On 11/24/11 13:22 , SM wrote:
 Hi Brian,
 At 12:02 24-11-2011, Brian E Carpenter wrote:
 Only for intellectual property issues. For other liabilities, the
 insurance is carried by ISOC as Francis says. But I don't see the
 relevance - if operators or users break legal requirements, that is
 nothing to do with the IETF anyway. Read the AS IS disclaimer found in
 older RFCs and now part of the Trust's legal conditions.
 
 I think that Francis' point is that the authors are writing a
 specification which, if implemented, may be illegal to deploy in some
 jurisdictions.  It's premature to draw any conclusion about the merits
 of the draft at such an early stage.

Lots of things done on the internet using internet standards no less are
potentially or actually illegal somewhere.

I can roll my IETF timeline back to the last decade of the 20th century
and cruise the various debates, on the presence or lack thereof of
encryption, export/import restriction, lawful interception, and more
recently both privacy and identity exposure requirements.

If I were to come to ay conclusion, it's likely that it would be that
there are no axioms.

having had the pleasure as an operator of deploying services in
jurisdictions with something approaching mutually exclusive requirements
I'm going not expect that we can satisfy everyone.

 There has been a few drafts recently on which questions about privacy
 were raised.  If privacy wasn't an issue, the web would be faster (
 www.afasterinternet.com ).  The discussions in several working groups
 point to a privacy void, i.e. there isn't any guidance about limiting
 data exposure when designing a protocol.
 
 Regards,
 -sm
 ___
 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] Recycle IPv4 bits

[Joel Jaeggli]

Joel's widget number 2

On Apr 6, 2011, at 17:23, Templin, Fred L fred.l.temp...@boeing.com wrote:

 Hi Iljitsch, 
 
 -Original Message-
 From: int-area-boun...@ietf.org 
 [mailto:int-area-boun...@ietf.org] On Behalf Of Iljitsch van Beijnum
 Sent: Wednesday, April 06, 2011 1:54 PM
 To: Templin, Fred L
 Cc: Internet Area
 Subject: Re: [Int-area] Recycle IPv4 bits
 
 Hi Fred,
 
 On 6 apr 2011, at 19:47, Templin, Fred L wrote:
 
 de facto IPv4 
 PMTUD only works with TCP
 
 While it is true that some UDP applications have no way
 to reduce the size of packets they send (and therefore
 set DF=0), I don't think it is possible to say that
 PMTUD only works with TCP. Do you know of any surveys
 showing that PMTUD is broken for other than TCP?
 
 Only what I've seen myself.
 
 You're right of course that there is no reason why IPv4 can't 
 handle this at the IP layer like IPv6 does, but it just 
 doesn't happen in practice. Hence the de facto above.
 
 It's such a shame that we never got this right. Maybe with IPvA...
 
 Any ideas on how we are going to get to 9KB jumbograms
 everywhere then, or are we just going to punt on that?

Still need pmtud when you have jumbo frames support because you don't know how 
many encapsulations there are on the wire. 

 Thanks - Fred
 fred.l.temp...@boeing.com
 
 ___
 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] draft-george-ipv6-required-01.txt --- what about IPsec ?

[Joel Jaeggli]

On 3/29/11 6:42 AM, Francis Dupont wrote:
  In your previous mail you wrote:
 
I fear IPsec required for IPv6 would slow deployment of IPv6.

Simply put it's been ignored so far whenever it's convenient which
appears to be frequently. I don't see that changing and our document
series (to Francis's point) appears to be updating in favor of reality.

 = IMHO it doesn't matter as the IETF has *no* way to enforce
 such a thing: you can require IPv6 boxes to be blue with red points,
 it will have the same effect (other to show it is ridiculous :-).
 BTW this was fixed in the requirements for IPv6 nodes and similar
 documents.
 
 Regards
 
 francis.dup...@fdupont.fr
 ___
 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-george-ipv6-required

[Joel Jaeggli]

On 1/10/11 7:36 PM, Ed Jankiewicz wrote:
 upon reflection, I agree that it would be unnecessary and inappropriate
 to generate a petition within IETF.  The process is built on consensus,
 not name-checking.
 
 Suffice it to say I support this work being discussed within Intarea and
 v6ops, including time on the agenda in Prague, and eventual adoption as
 a WG or IAB publication.
 
 I also agree with a previous comment that this draft should be kept very
 simple with a small number of essential references, e.g. to the IPv6
 Node Requirements (as revised).  That is the current best definition of
 what is required for IPv6.  If it is insufficient as is, and needs to
 be replaced by a standards track definition, that would take some
 effort, and that can be discussed as well.  I would prefer that we
 publish the current RFC 4294 update draft before we open that can of worms.
 
 The question of parity is very complex and difficult to define. 

more to the point consensus on what constitutes  is a discussion that's
pretty easy to rathole. A statement that is simplistic and open to
interpretation may not achieve all that you want at the same time the
resulting statement may be more readily achievable and we have documents
like for example the cpe drafts to addresses.

Idealy this document is:

1. discussed now both here and the int-area.
2. presented in prague
3. accepted as a wg document where we deem appropiate
4. last called

 The
 concerns that some things are not directly comparable, or that there are
 things that have become accepted in IPv4 that some don't want to
 replicate in IPv6, versus the sense that the lack of any feature
 (standard or not) will be a disincentive to IPv6 adoption - it's not
 clear how these can be reconciled.
 
 On 1/10/2011 11:29 AM, George, Wes E [NTK] wrote:
 Shortened the subject line a bit

 From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On
 Behalf
 Of Ed Jankiewicz
 Sent: Friday, January 07, 2011 3:11 PM
 To: int-area@ietf.org; IPv6 Operations
 Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new
 draft-george-ipv6-required

 I agree so strenuously that I half-jokiningly would like to be listed
 as a
 coauthor, and I bet there are anumber of other folks on these lists
 that
 would feel the same way.  Perhaps a better suggestion would be
 toinclude an
 appendix with the name and affiliation of everyone who is willing to
 sign-on
 to ratify thisrecommendation.
 [WES] If I'm interpreting this right, this would sort of be like a
 petition
 with lots of signatures, or one of those open letters to the
 $government_functionary signed by lots of important people you see
 published
 in full-page newspaper ads? I assume that this is generally a way of more
 concretely documenting support for this proposal beyond the IETF's
 standard
 rough consensus in a WG meeting or on-list.
 I'm open to this, but is there any precedent for it? Do we want to set a
 precedent that if we *really* mean something, we take steps to more
 thoroughly
 document that support within a draft? Those in support can already
 have their
 support immortalized in the pages of the email list archives complete
 with
 their choice of editorialization...
 And regarding affiliation - IETF typically shies away from making a
 big deal
 of affiliation, since most of its members are not really authorized to
 represent the company that pays the bills in any official public
 capacity.
 Yes, they are representatives of that company, but they are mostly
 speaking
 for themselves with the interests of their company informing those
 comments -
 it's not like there's a way to get every email and comment at the mic
 approved
 by PR first :-)

 An IAB statement of support would perhaps be a good way to add weight
 to this
 recommendation, but I'm content to start with statements of support
 for WG
 adoption and advancement to RFC status and see where it goes from there.

 Wes George
 

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

Re: [Int-area] [v6ops] End-to-end address transparency

[Joel Jaeggli]

On 1/10/11 9:50 PM, Fernando Gont wrote:
 On 10/01/2011 05:43 p.m., Mark Smith wrote:
 
 The e2e transparency that IPv4 had lost, and IPv6 restores, is
 ADDRESS transparency: source and destination addresses seen by a
 destination are the same as those set by the source. 

 IPv6 restores this to the extent that NAT66 is not deployed. My take is
 that NAT66 *will* be deployed. 

 How do you know? What evidence do you have?
 
 Talking to vendors, some operators, etc.
 
 Google for ipv6 nat or the like, and you'll see some of the people
 that are publicly interested in this feature.

It's a basic and necessary feature of ipv6-supporting loadbalancer devices.

Given that header rewriting, and state-tracking are basic firewall
functions for v4 and v6 you really aren't very far conceptually or
implementation-wise from a nat66 feature.

The question is what's it a point solution for. If the problem is, you
gave me one ip address and i need more than that something is badly wrong.

 
 
 -- So, I don't think you can rely IPv6 on
 restoring address transparency.

 - This is needed
 in particular for Header Authentication of IPsec. 

 But you can still use UDP encapsulation.

 UDP encapsulation of IPsec is a work around, specifically to get around
 the problems of lack of IPv4 address transparency i.e. NAT. It isn't an
 acceptable answer when NAT doesn't need to exist.
 
 You're assuming that the only motivation to have NATs is address
 exhaustion -- but IMO, it isn't.
 
 Thanks,

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

Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]

[Joel Jaeggli]

On 10/15/10 10:33 AM, Fernando Gont wrote:
 On 05/10/2010 08:04 p.m., Joel Jaeggli wrote:
 
 It is much worse.  At the IP and Transport level functionality, the
 IPv4 Internet is essentially frozen somewhere in the 1990's.  Sad...

 Now is not the point to invest time fixing the ipv4 internet.
 
 Unless you expect that it will be *replaced* in 5 years or so with
 something else, I'd argue Why not?. 

because the software and stack have already osified. existing systems
are not going to pick up changes that you implement particularly in the
waist of the hourglass. That's just reality.

 There are estimates of 15-20 more
 years of living with IPv4, so

you're going to have 20 years of supporting the assumptions currently
present in legacy systems.

 Thanks,

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

Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]

[Joel Jaeggli]

On 10/15/10 11:44 AM, Noel Chiappa wrote:
  From: Joel Jaeggli joe...@bogus.com
 
  because the software and stack have already osified. 
 
 The implication being that that's not true for IPv6?

However painful it may be, altering the stacks of devices not yet built
is easier than that of those already in the field.

 That will please the
 ILNP people to hear, I'm sure, what with ILNP being the official RRG
 recommendation for multi-homing support (now that MULTI6 has been turned down
 by the users) - since ILNP requires changes to the host stacks (in the IPv6
 and TCPv6 code). So how well you do think that change will be accepted by
 the v6 host community?

I believe the word you're looking for is recalcitrant.

   Noel
 

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

Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]

[Joel Jaeggli]

On 10/5/10 6:47 PM, Bob Hinden wrote:
 Dan,
 
 No.  It's very likely only gotten work since the 2004 paper.
 
 Off list, someone else suggested it had gotten better.  So I tested
  the top sites from Alexa's list using NMAP, and results were:
 
 TCP 3-way handshake without IP option:  99% success TCP 3-way
 handshake with IP option:  9% success
 
 NMAP commands, input, and output are at: 
 http://www.employees.org/~dwing/ipoptions/
 
 
 It is much worse.  At the IP and Transport level functionality, the
 IPv4 Internet is essentially frozen somewhere in the 1990's.  Sad...

Now is not the point to invest time fixing the ipv4 internet.

  Bob
 
 
 ___ 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] Review of draft-narten-ipv6-3177bis-48boundary-05

[Joel Jaeggli]

On 8/20/10 4:00 PM, Fred Baker wrote:
 
 On Aug 20, 2010, at 2:55 PM, Eric Gray wrote:
 
 Following the CIDR model for IPv6 seems to allow for as many as (on
 the order of) 7-10 times as many possibly usable address allocation
 sizes.
 
 Well, yes, saying that you can pick any length you like gives the
 address allocation authorities, at least in theory, 64 orders of
 magnitude.
 
 There is a line of reasoning, which I subscribe to, that all of those
 options really aren't needed, and that there are human factors
 reasons to prefer prefix lengths on nibble (hex digit) boundaries.
 Not that allocations like 192.0.2.20/30 are impossible to grok -
 they're not - but if we have the opportunity to simplify things, why
 not?
 
 One comment that comes to mind is a recent conversation with my son.
 He works for a company that makes radio-controlled model airplanes,
 the kind that have a 66 foot wingspan and shoot missiles. The planes
 are full of computers, and no they don't ask the DNS root to
 translate names. If you're in one of those computers and need to talk
 with another one, you need to know its IP address. So he is used to
 being in computer A and logging into computer B as 192.0.2.17 or
 whatever.
 
 He and I spoke a few weeks about, and he asked Dad, when you guys
 were designing IPv6, did you think at all about how LONG those
 addresses were?
 
 ta-dum!
 
 Now ask yourself about being in my daughter's network (women enter
 her home as the girl-next-door and leave beautiful), telling her that
 she can use anything she likes in 2001:0db8:2775:1234/62, and having
 her notice that the address of something or another is
 2001:0db8:2775:1235... In IPv4, I said deal with it, you have to be
 somewhat technical. In IPv6, I would like to not have to go there.
 It's not her expertise, and she doesn't ask me to cut/color her hair
 either.
 
 So, yes, I tend to think that the common rabble should deal with
 addresses that break on nibble boundaries.

As I observed not so long ago at a v6ops wg meeting. having your your
foo object (in the case described a point to point link) aligned on
octet or nibble boundaries makes them way easier to read. have a few
thousands 126 or 127 prefixes in a row and it kind of looks like fruit
salad.

Just because the robots don't have trouble with it doesn't mean the
humans  shouldn't be accommodated.

 That has nothing to do with RIRs or service providers, mind you; they
 are often somewhat technical. Within their networks I expect them
 to do what makes sense to them, and I regard myself more as their
 student than their teacher... 
 ___ 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