Hi Robin, >-----Original Message----- >From: Robin Whittle [mailto:[EMAIL PROTECTED] >Sent: Sunday, April 06, 2008 4:24 AM >To: Routing Research Group; Templin, Fred L >Subject: SEAL, PMTUD, IPv6 header bloat, header compression > >Hi Fred, > >in two messages in the "Is ISATAP a practical solution" you >mentioned some things to do with the problem of Path MTU Discovery >for ITRs to ETRs, fragmentation of packets etc. - and your SEAL >proposal which intended to help with these. > > http://tools.ietf.org/html/draft-templin-seal-04 (new today) > >I haven't read SEAL in detail yet.
Now at -05; hopefully not to change for a while. >I wrote, in: > > http://psg.com/lists/rrg/2008/msg01112.html > > I have a dimmer view of IPv6 than many IETF folks. I think 64 > bit addresses would have been better. With 128, there are 32 > bytes of address in every packet - which seems like overkill > when there are millions of people sending two-way streams of 50 > VoIP packets a second with only 20 bytes of payload. However > there are creative uses of the extra bits, such as Six/One. > > This address burden gets worse with any map-encap tunneling > header, so I am keen to keep Ivip encapsulation as minimal as > possible: IP-in-IP. LISP involves a LISP header and therefore a > UDP header as well. I am also keen to avoid anything like a > SEAL header, at least on the shorter packets in any map-encap > tunnel. > >and: > > The one thing I could imagine making IPv4 completely unworkable > would be every cellphone on the planet having its own mobile > public IP address, which I think could be done with the > map-encap approach to mobility. Since there are 3.3 billion > such devices now, IPv4 could never do that. But then think of > those bloated IPv6 addresses chewing up bandwidth on cell-phone > radio links carrying streams of VoIP packets. > > >However when I wrote this, I was also thinking of the map-encap >headers with at least two sets of IPv6 source and destination >address (inner payload packet and the encapsulation header) going >over the mobile link - which would be horrible. This isn't right. >In the TTR-based model of mobility with map-encap schemes, the >mobile node (MN) has its own (potentially proprietary) 2-way tunnel >to the nearby TTR. Apart from the basic IPv6 header, the lengthy >additional header stuff to do with the map-encap scheme I was >discussing in the first two paragraphs above only travels in the >ITR->ETR part of the path, and the TTR plays the role of ETR. So >map-encap headers, SEAL headers etc. don't need to go to the MN. Correct - no map-encaps or SEAL headers to the MN. SEAL is for use in router-to-router tunneling in-the-network. Low-end systems would not see the encapsulation headers; they would only see their native-link first-hop routers which would eventually deliver their packets to an ITR or from an ETR somewhere else in the network. >You responded to the third paragraph above: > >> Again, header compression has been proposed. > >OK - a suitably sophisticated header compression on the radio link >would be able to find the repetitive parts of streams of VoIP >packets etc. and compress their IPv6 headers, and perhaps their UDP >are RTP headers significantly. > >Header compression could also be done in the MN <--> TTR protocol. OK; I will read about TTR. >>> I am also keen to avoid anything like a SEAL header, at least >>> on the shorter packets in any map-encap tunnel. >> >> Including the SEAL header on large packets and omitting >> it on smalls is certainly an idea to be taken seriously >> and not to be dismissed w/o further consideration. However, >> reasons we might not want to do that include: >> >> 1) multiple encapsulation formats on the same link; could >> confuse both tunnel endpoints and middleboxes >> >> 2) omission of SEAL header reduces identification to >> only 16 bits; may not be sufficient for duplicate >> packet and/or off-link attack detection >> >> What are your thoughts on this? > >I will have to read the SEAL material before commenting further, but >I think it is really important to avoid extra headers unless they >are really needed - especially for the vast streams for small >packets such as VoIP. As above, the low-end systems and edge networks would not see the extra headers; only the in-the-network router-to-router tunnels would. >> BTW, the idea of extending the IPv4 ID to 32 bits in a >> manner similar to the way SEAL does it is not new. The >> earliest proposal to do this (which I came across after >> publishing SEAL) was from Steve Deering on the mtudwg >> mailing list in Feb. 1990: >> >> http://ipvlx.org/mtudwg-log >> >> but I wouldn't be surprised if there were still >> earlier proposals. The primary difference between what >> SEAL is doing and what Steve articulated was that Steve >> proposed a new IPv4 option, whereas SEAL proposes a new >> IPv4 protocol. > >New IPv4 header options are not practical since DFZ routers won't >handle them quickly (or perhaps at all?). Right; I am only giving an historical account and not a proposal to use IP options. See also: "IP Options are not an Option": http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf > A map-encap system >definitely needs a solution to the PMTUD and fragmentation problems. > I am hoping to do it in Ivip without any extra headers in the >traffic packets, and with a new protocol for ITRs probing PMTU to >ETRs. As our discussions last year showed, this is a really >difficult business. Based on what I can tell, a lot of people have been thinking about this for a long time now. For years, I have been striving for perfection, but am now beginning to doubt that is possible. Instead, I think what SEAL has now is "pretty good" and perhaps even "good enough". >I won't be updating my plans, currently >summarised at: > > http://www.firstpr.com.au/ip/ivip/pmtud-frag/ > >until I have read your SEAL proposal and given it a lot more thought. Thanks - Fred [EMAIL PROTECTED] > > - Robin > -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
