Re: UDP+Fragmentation (was: Deprecate)
in http://www.ietf.org/mail-archive/web/ipv6/current/msg18703.html). If the above reasoning is correct, then my inclination is to deal with the issue explicitly in the transport layers that need to deal with it (which would put the problem in the domain of TSVWG). That seems cleaner than intertwining the IP and transport layers (though in practice these layers are often tightly coupled anyway). If there are any operations people listening in, it would be helpful to get some feedback on whether this reasoning is correct. It would also be helpful to get some indication on whether a modified UDP or a new UDP-like protocol that supports transport layer payload segmentation solves enough problems to be worth the effort to specify, implement, and deploy. At the moment, the only compelling use case seems to be DNS (and more particularly DNSSEC). There is already a work-around in that case, namely TCP, which was made mandatory in 2010 by RFC 5966 to work around firewalls that routinely block fragmented IP packets and network devices [that] deliberately refuse to handle DNS packets containing EDNS0 options. Clearly, making a new or modified UDP-like transport protocol is not sufficient; applications that want to use it would need a means to signal that they support it and/or a means to query whether their peers support it. In the case of DNS that would presumably mean something like a new EDNS0 option. The question arises whether the effort involved in making these changes would be worthwhile, given that TCP is already available as a workaround. Thanks and regards, Mike Heard IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [6MAN] UDP+Fragmentation (was: Deprecate)
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. -- J.R.R. Tolkien IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: draft-andrews-6man-fragopt updated
In message pine.lnx.4.64.1308260755110.19...@shell4.bayarea.net, C. M. Heard writes: On Mon, 19 Aug 2013, C. M. Heard wrote: On Tue, 6 Aug 2013, Mark Andrews wrote: http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt ... In answer to to the open questions, I would suggest using a single option code and making the protocol explicit. The strategy of leaving the protcol implicit leads to ambigiuities (e.g., between TCP, UDP, and UDP-lite). I would also suggest judicious use of padding to align 4 and 8 bytes quantities on natural boundaries. It occurs to me that instead of having a different option format for every single upper-layer protocol, one could instead just package the portion of the header chain (extension headers, if any, and upper-layer header) that appears after the fragmentation header in the initial fragment. That would require only a single option code, would apply to all present and future upper-layer protocols, and would provide the requisite upper-layer information in a form that those who want it must already know how to parse. The option would look like this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1| (TBD) | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Portion of header chain following offset=0 fragment header + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type would be chosen to indicate that the option is mutable and is to be skipped if it is not recognized. The alignment requirement would be 8n+6, since the upper-layer header and any preceding extension headers always are aligned on 8-octet boundaries. Here are some other suggestions: - Make this a destination option that appears before the fragmentation header, not a hop-by-hop option, as discussed in a previous e-mail in this thread. It is quite possible to develop asics which understand this option the same way as there are asics which process tcp and udp headers. - This option MUST NOT appear in an initial fragment (or in an unfragmented fatagram). That avoids the possibiity that a middlebox will interpret a datagram differently from an end system (or another middlebox). This is a non starter. Whatever change we make needs to be visible in all fragment. Firewalls need to be able to identify if the packet is following old fragmentation rules or new fragmentation rules so it can decide if it is applying old policy or new policy. - New end-system implementations MUST have the capability to insert this option in non-initial fragments. That capability MUST be configurable, and the default SHOULD be to insert the option. - If a forwarding node discards a packet containing this option, it MUST be the result of a configurable policy, and not just the result of a failure to recognize the option. By default, the policy SHOULD be the same that the node would apply to an initial fragment with the same header chain that is in the option, and that in turn SHOULD be the same policy that the node would apply to an unfragmented datagram with the same header chain (less the fragmentation header). - A forwarding node that rewrites the flow label MAY use the information available in this option for that purpose. - An end system is not required to process this option. However, if it does, it SHOULD ensure that the copies the upper-layer in the various fragments match what appears in the initial fragment, and that the option does not appear in an initial fragment (or in an unfragmented datagram). [Define codes and pointers for an ICMPv6 Parameter Problem message that indicates these situations.] Acknowledgments to draft-ietf-6man-ext-transmit-03 for some stolen text. Item for discussion: does it really matter whether or not this option is marked as mutable? It would not be covered by an Authetication Header in any case since AH is applied only to whole IP datagrams (not to IP fragments) [RFC 2402] and this option is inserted only after fragmentation. A NAT does not respect immutability (as defined in RFC 2402), so the possibility of a NAT being on the path does not seem like a good reason to mark it mutable. On the other hand, what benefit could there be from marking it as immutable? Mike Heard IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: draft-andrews-6man-fragopt updated
In message pine.lnx.4.64.1308261732510.29...@shell4.bayarea.net, C. M. Heard writes: On Tue, 27 Aug 2013, Mark Andrews wrote: In message pine.lnx.4.64.1308260755110.19...@shell4.bayarea.net, C. M. Heard writes: Here are some other suggestions: - Make this a destination option that appears before the fragmentation header, not a hop-by-hop option, as discussed in a previous e-mail in this thread. It is quite possible to develop asics which understand this option the same way as there are asics which process tcp and udp headers. could be developed != exists in current core routers Existing core routers are likely to punt hop-by-hop options to a slow path. But they aren't the cause of the fragment dropping problems. So we should seek a solution that does not require updating them. Some punt them to the slow path but fragmented IP is also a small percentage of traffic. Others just don't process hop-by-hop. Others just drop. I don't see why a destination option (apearing BEFORE the fragment header) would not work just as well as a hop-by-hop option while being immune from this particular problem. - This option MUST NOT appear in an initial fragment (or in an unfragmented fatagram). That avoids the possibiity that a middlebox will interpret a datagram differently from an end system (or another middlebox). This is a non starter. Whatever change we make needs to be visible in all fragment. Firewalls need to be able to identify if the packet is following old fragmentation rules or new fragmentation rules so it can decide if it is applying old policy or new policy. I don't see that. Lots of firewalls discard all fragments as it is pointless sending the initial fragment if you are discarding non-initial fragments. As for mis-matches they are expected if you have NATs in the path. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: UDP+Fragmentation
In message 2134f8430051b64f815c691a62d983180e2...@xch-blv-504.nw.nos.boeing.co m, Templin, Fred L writes: Hi Mark, -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Wednesday, August 07, 2013 4:56 PM To: Templin, Fred L Cc: Doug Barton; ipv6@ietf.org Subject: Re: UDP+Fragmentation In message 2134F8430051B64F815C691A62D983180E1E06@XCH-BLV- 504.nw.nos.boeing.co m, Templin, Fred L writes: Hi Mark, -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Wednesday, August 07, 2013 2:54 PM To: Templin, Fred L Cc: Doug Barton; ipv6@ietf.org Subject: Re: UDP+Fragmentation In message 2134F8430051B64F815C691A62D983180E170A@XCH-BLV- 504.nw.nos.boeing.co m, Templin, Fred L writes: Hi Mark, -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, August 06, 2013 7:32 PM To: Templin, Fred L Cc: Doug Barton; ipv6@ietf.org Subject: Re: UDP+Fragmentation In message 2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV- 504.nw.nos.boeing.com, Templin, Fred L writes: On 08/06/2013 03:07 PM, Templin, Fred L wrote: If we are going to define a new protocol type, let's define one that addresses everything we are currently struggling with and has the extensibility to address additional requirements moving forward into the future. So in other words let's make all the same mistakes we made with the design of IPv6? :) Not even. This is about fixing and atoning for mistakes; not introducing new ones. Thanks - Fred fred.l.temp...@boeing.com - --- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 - --- There are several issues with getting fragments through firewalls. My draft addresses one of them. Putting all the headers into the initial fragment is another part of fix / reducing the issue. If you don't do something like that firewall will drop initial fragments because that can't be expected to reassemble unless they are doing DPI. Making fragment sizes more even is yet another part of the issue. Allowing tunnel entry points to re-fragment fragments is yet another part of the solution space. In these points, you are making a good case for SEAL. And all those changes are independent of a SEAL header. They are changes to the fragmentation algorithm. But, an attacker does not need to implement the changes to the fragmentation algorithm in order to be compliant with the specs. SEAL has a big drawback. SEAL requires then tunnel endpoint / destination node to understand SEAL. Right that the destination needs to understand SEAL. My draft does not require any other node to understand the option. You can start sending packets with the option immediately and they should be passed by nodes that are not aware of what it does. Destination nodes can process the fragments without knowning the contents. This is no more dangerous than processing fragmented traffic without the option if you are already passing fragments. But, does it address the tiny fragment attack profile that Ron's draft is concerned with? And will it be robust as more and more operators unconditionally drop IP fragments? Fred, you are missing the point. You don't need a single ominbus draft. One can have multiple drafts that address different points. You know, I was thinking pretty much the same thing on my way into work today. SEAL didn't set out to address transport mode, and until the most recent version left it as out of scope. I'm willing to believe that an incrementally deployable approach such as what you are describing could address transport-specific requirements. Your arguement is that it is not a omnibus draft. It didn't set out to be a omnibus draft. OK. Today legitimate IPv6 nodes send fragments no smaller than 1280 unless the first hop is being mapped to IPv4 at the sending node and the IPv4 mtu is less than 1280. 1280 bytes contains the full header chain unless someone is launching a attack. Today firwalls drop fragments that don't have enough information in them to work out if the non-initial fragment can pass without passing all fragments. The initial fragment is dropped because the firewall operator knows it is pointless to send it despite there being enough information. If attackers sends tiny fragments they will continue to be dropped
Re: UDP+Fragmentation
In message 2134f8430051b64f815c691a62d983180e1...@xch-blv-504.nw.nos.boeing.co m, Templin, Fred L writes: Hi Mark, -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, August 06, 2013 7:32 PM To: Templin, Fred L Cc: Doug Barton; ipv6@ietf.org Subject: Re: UDP+Fragmentation =20 =20 In message 2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV- 504.nw.nos.boeing.com, Templin, Fred L writes: On 08/06/2013 03:07 PM, Templin, Fred L wrote: If we are going to define a new protocol type, let's define one that addresses everything we are currently struggling with and has the extensibility to address additional requirements moving forward into the future. So in other words let's make all the same mistakes we made with the design of IPv6? :) Not even. This is about fixing and atoning for mistakes; not introducing new ones. Thanks - Fred fred.l.temp...@boeing.com IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 =20 There are several issues with getting fragments through firewalls. My draft addresses one of them. =20 Putting all the headers into the initial fragment is another part of fix / reducing the issue. If you don't do something like that firewall will drop initial fragments because that can't be expected to reassemble unless they are doing DPI. =20 Making fragment sizes more even is yet another part of the issue. =20 Allowing tunnel entry points to re-fragment fragments is yet another part of the solution space. In these points, you are making a good case for SEAL. And all those changes are independent of a SEAL header. They are changes to the fragmentation algorithm. SEAL has a big drawback. SEAL requires then tunnel endpoint / destination node to understand SEAL. My draft does not require any other node to understand the option. You can start sending packets with the option immediately and they should be passed by nodes that are not aware of what it does. Destination nodes can process the fragments without knowning the contents. This is no more dangerous than processing fragmented traffic without the option if you are already passing fragments. The key difference is HEADER vs OPTION. Mark Thanks - Fred fred.l.temp...@boeing.com Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: UDP+Fragmentation
In message 2134f8430051b64f815c691a62d983180e1...@xch-blv-504.nw.nos.boeing.co m, Templin, Fred L writes: Hi Mark, -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Wednesday, August 07, 2013 2:54 PM To: Templin, Fred L Cc: Doug Barton; ipv6@ietf.org Subject: Re: UDP+Fragmentation =20 =20 In message 2134F8430051B64F815C691A62D983180E170A@XCH-BLV- 504.nw.nos.boeing.co m, Templin, Fred L writes: Hi Mark, -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, August 06, 2013 7:32 PM To: Templin, Fred L Cc: Doug Barton; ipv6@ietf.org Subject: Re: UDP+Fragmentation =3D20 =3D20 In message 2134F8430051B64F815C691A62D983180E0E2C@XCH-BLV- 504.nw.nos.boeing.com, Templin, Fred L writes: On 08/06/2013 03:07 PM, Templin, Fred L wrote: If we are going to define a new protocol type, let's define one that addresses everything we are currently struggling with and has the extensibility to address additional requirements moving forward into the future. So in other words let's make all the same mistakes we made with the design of IPv6? :) Not even. This is about fixing and atoning for mistakes; not introducing new ones. Thanks - Fred fred.l.temp...@boeing.com - --- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 - --- =3D20 There are several issues with getting fragments through firewalls. My draft addresses one of them. =3D20 Putting all the headers into the initial fragment is another part of fix / reducing the issue. If you don't do something like that firewall will drop initial fragments because that can't be expected to reassemble unless they are doing DPI. =3D20 Making fragment sizes more even is yet another part of the issue. =3D20 Allowing tunnel entry points to re-fragment fragments is yet another part of the solution space. In these points, you are making a good case for SEAL. =20 And all those changes are independent of a SEAL header. They are changes to the fragmentation algorithm. But, an attacker does not need to implement the changes to the fragmentation algorithm in order to be compliant with the specs. SEAL has a big drawback. SEAL requires then tunnel endpoint / destination node to understand SEAL. Right that the destination needs to understand SEAL. My draft does not require any other node to understand the option. You can start sending packets with the option immediately and they should be passed by nodes that are not aware of what it does. Destination nodes can process the fragments without knowning the contents. This is no more dangerous than processing fragmented traffic without the option if you are already passing fragments. But, does it address the tiny fragment attack profile that Ron's draft is concerned with? And will it be robust as more and more operators unconditionally drop IP fragments? Fred, you are missing the point. You don't need a single ominbus draft. One can have multiple drafts that address different points. Your arguement is that it is not a omnibus draft. It didn't set out to be a omnibus draft. Today legitimate IPv6 nodes send fragments no smaller than 1280 unless the first hop is being mapped to IPv4 at the sending node and the IPv4 mtu is less than 1280. 1280 bytes contains the full header chain unless someone is launching a attack. Today firwalls drop fragments that don't have enough information in them to work out if the non-initial fragment can pass without passing all fragments. The initial fragment is dropped because the firewall operator knows it is pointless to send it despite there being enough information. If attackers sends tiny fragments they will continue to be dropped with or without this option as the firewall doesn't have enough information to make the decision in the initial fragment. Legitimate initial fragment however can now be let through as the firewall knows that the other fragments will have the necessary information. Other fragments can be let through with this option as the firewall will pass the legitimate initial fragment. Attackers now have to find the slot/pinhole to send attack traffic through instead of just letting through all fragments. Mark The key difference is HEADER vs OPTION. That's right, but without a new header there is no means to probe the path MTU or even to ping the destination to see if it is up as part of the protocol. Plus, we need a multiple-part solution that not only addresses transport-mode UDP fragmentation but also tunnel-mode operation for tunnels that would otherwise
Re: UDP+Fragmentation
In message 2134f8430051b64f815c691a62d983180e0...@xch-blv-504.nw.nos.boeing.com, Templin, Fred L writes: On 08/06/2013 03:07 PM, Templin, Fred L wrote: If we are going to define a new protocol type, let's define one that addresses everything we are currently struggling with and has the extensibility to address additional requirements moving forward into the future. So in other words let's make all the same mistakes we made with the design of IPv6? :) Not even. This is about fixing and atoning for mistakes; not introducing new ones. Thanks - Fred fred.l.temp...@boeing.com IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 There are several issues with getting fragments through firewalls. My draft addresses one of them. Putting all the headers into the initial fragment is another part of fix / reducing the issue. If you don't do something like that firewall will drop initial fragments because that can't be expected to reassemble unless they are doing DPI. Making fragment sizes more even is yet another part of the issue. Allowing tunnel entry points to re-fragment fragments is yet another part of the solution space. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
draft-andrews-6man-fragopt updated
http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: UDP+Fragmentation
In message 2134f8430051b64f815c691a62d983180df...@xch-blv-504.nw.nos.boeing.co m, Templin, Fred L writes: Hi Mike, -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of C. M. Heard Sent: Saturday, August 03, 2013 9:21 AM To: IPv6 Subject: Re: UDP+Fragmentation On Sat, 3 Aug 2013, Brian E Carpenter wrote: On 02/08/2013 18:12, Mark ZZZ Smith wrote: [ Mark ZZZ Smith wrote ] ... [ C. M. Heard wrote ] ... - generic transport encapsulation within UDP (suggested to me off-list by Mark Smith, based on a draft by Stuart Cheshire et. al.). ... May I make a plea for any such proposal to be carefully evaluated against common practices in stateful firewalls and load balancers. I'm rather concerned that the problems these middleboxes create with conventional fragmentation will soon come back with UDP-encapsulated fragmentation. (There is no problem in computer science that can't be made harder by recursion.) Yes, UDP-encapsulated fragmentation (in its simplest form) has exactly the same issue as conventional IP fragmentation -- it hides the actual L4 header information in all but the first fragment. Operators who filter conventional IP fragments would have exactly the same motivation to filter UDP-encapsulated fragments. On Thu, 1 Aug 2013, Mark ZZZ Smith wrote: (2) fragments can hide transport layer protocol ports, preventing simple ACL filtering etc. ... A general solution like SEAL (which I think in the big picture would be better), probably doesn't solve (2) SEAL transport mode, as currently proposed, addresses the problem by including port numbers in all non-initial segments:. See: https://tools.ietf.org/html/draft-templin-intarea-seal-61#page-32 Thanks for pointing this out. Another problem I have heard is that initial fragments are sometimes so small that the L4 information does not fit, or that non-initial fragments may sometimes overlap the initial fragment and invalidate any filtering checks that were applied to the initial fragment. SEAL addresses this by requiring that the initial fragment be at least 256 bytes in length and that all fragments except the final one contain an integer multiple of 256 byte blocks. Overlapping fragments are also explicitly forbidden. Thanks - Fred fred.l.temp...@boeing.com Mike Heard IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 SEAL however doesn't appear to be incrementally deployable. You need the destination to be SEAL aware as it is a destination header not a destination option. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: UDP+Fragmentation
In message 20130806014122.690c43809...@drugs.dv.isc.org, Mark Andrews writes: In message 2134f8430051b64f815c691a62d983180df...@xch-blv-504.nw.nos.boeing. co m, Templin, Fred L writes: Hi Mike, -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of C. M. Heard Sent: Saturday, August 03, 2013 9:21 AM To: IPv6 Subject: Re: UDP+Fragmentation On Sat, 3 Aug 2013, Brian E Carpenter wrote: On 02/08/2013 18:12, Mark ZZZ Smith wrote: [ Mark ZZZ Smith wrote ] ... [ C. M. Heard wrote ] ... - generic transport encapsulation within UDP (suggested to me off-list by Mark Smith, based on a draft by Stuart Cheshire et. al.). ... May I make a plea for any such proposal to be carefully evaluated against common practices in stateful firewalls and load balancers. I'm rather concerned that the problems these middleboxes create with conventional fragmentation will soon come back with UDP-encapsulated fragmentation. (There is no problem in computer science that can't be made harder by recursion.) Yes, UDP-encapsulated fragmentation (in its simplest form) has exactly the same issue as conventional IP fragmentation -- it hides the actual L4 header information in all but the first fragment. Operators who filter conventional IP fragments would have exactly the same motivation to filter UDP-encapsulated fragments. On Thu, 1 Aug 2013, Mark ZZZ Smith wrote: (2) fragments can hide transport layer protocol ports, preventing simple ACL filtering etc. ... A general solution like SEAL (which I think in the big picture would be better), probably doesn't solve (2) SEAL transport mode, as currently proposed, addresses the problem by including port numbers in all non-initial segments:. See: https://tools.ietf.org/html/draft-templin-intarea-seal-61#page-32 Thanks for pointing this out. Another problem I have heard is that initial fragments are sometimes so small that the L4 information does not fit, or that non-initial fragments may sometimes overlap the initial fragment and invalidate any filtering checks that were applied to the initial fragment. SEAL addresses this by requiring that the initial fragment be at least 256 bytes in length and that all fragments except the final one contain an integer multiple of 256 byte blocks. Overlapping fragments are also explicitly forbidden. Thanks - Fred fred.l.temp...@boeing.com Mike Heard IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 SEAL however doesn't appear to be incrementally deployable. You need s/incrementally/opportunistically/ the destination to be SEAL aware as it is a destination header not a destination option. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: UDP+Fragmentation
In message pine.lnx.4.64.1308051910030.31...@shell4.bayarea.net, C. M. Heard writes: On Tue, 6 Aug 2013, Mark Andrews wrote: SEAL however doesn't appear to be incrementally deployable. You need the destination to be SEAL aware as it is a destination header not a destination option. Except for the hop-by-hop option proposal in http://tools.ietf.org/id/draft-andrews-6man-fragopt all of the proposals informally floated so far suffer from that disadvantage. That includes a new version of UDP with segmentation, generic transport encapsulation within UDP, and SEAL. As mentioned elsewhere, generic transport encapsulation within UDP does not really address the problem, as it lacks L4 header information in all fragments except the first (see http://www.ietf.org/mail-archive/web/ipv6/current/msg18687.html). The hop-by-hop option proposal and SEAL suffer from a security hole: the L4 information is duplicated, and thereby creating a security hole. An attacker could put one thing in the option or in the SEAL header (to be interpreted by a middlebox) and another thing in the actual transport header (to be interpreted by an end system). A new version of UDP would not have this problem, as the same header would be interpreted by both the middlebox and the end system. Actually draft-andrews-6man-fragopt doesn't as the option is in all fragments and policy devices can decide whether to pass mis-matching initial fragments or not. I don't see policy devices passing non-initial fragments where you can't do this check. A filter rule like pass dstport 80 srcport any would enforce that destination ports matched but wouldn't care that the source ports didn't. The hop-by-hop option proposal suffers from another problem. Quoting from http://tools.ietf.org/id/draft-ietf-6man-ext-transmit-02.txt Section 2.2: It is to be expected that high performance routers will either ignore it, or assign packets containing it to a slow processing path. Designers planning to use a Hop-by-Hop option need to be aware of this likely behaviour. The problem in the present case arises if high performance routers put packets with hop-by-hop options on a slow path. Well properly design your router. It is a design choice to slow path hop-by-hop processing. //cmh IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Deprecate
In message 2134f8430051b64f815c691a62d983180dc...@xch-blv-504.nw.nos.boeing.co m, Templin, Fred L writes: Hi Ran, Discussion: Deployments using tunnels, whether IP-in-IP, GRE, IPsec tunnel-mode, or some other IETF specified technology, are NOT going away. Yes, this is the same as I and others have been saying all along. If the physical MTU is 1280, then the tunnel MTU will be smaller. Not allowed; the tunnel MUST be able to do a minimum 1280. Nested tunnels are not unusual and can be difficult to detect absent a working PMTUD mechanism (whatever that might be). Agree that nested tunnels are not unusual and are in fact in common widespread deployment. But, there is no need to detect them from the source host's perspective as long as they honor the IPv6 1280 minMTU. That means that tunnels MUST be prepared to do a small amount of fragmentation and reassembly when necessary. And if we generate appoximately equal sized fragments rather than 1280 byte fragments + a runt fragment tunnels would need to fragment less often. Your 1500 byte UDP payloads become 2 x 750 byte fragments which can be encapulated multiple times. It doesn't take a lot of math to work out what size to fragment at to produce optimal fragment sizes for a given MTU. Mark Thanks - Fred fred.l.temp...@boeing.com IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Deprecate
Mark Andrews writes: I can write up my suggestion as a I-D. It provides the information stateless middleware needs to pass fragments. It also helps firewalls that decide they need to see the entire contents of packets by providing protection to their reassembly queues. Done. http://www.ietf.org/id/draft-andrews-6man-fragopt-00.txt -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Deprecate
In message 44c69d85-ea12-422e-a1dc-7f1ee8133...@apple.com, james woodyatt wri tes: On Jul 30, 2013, at 15:25 , Ronald Bonica rbon...@juniper.net wrote: I disagree. Aside from the advice that you quote below, the draft does two things: - It admits that there is an operational problem - It instructs the IETF not to make the problem worse by standardizing yet more applications that rely upon fragmentation. I'm not sure how we are in disagreement, but I still sense we are disagreeing . Somehow. I think the above two things are useful things for IETF to do, and they are r easons to publish an RFC to do it. I also think it isn't a good idea to advi se maintainers [like me] of host stacks with legacy application and transport protocols to consider breaking their dependence on IPv6 fragmentation. (Thi s is one of those moments where I wish I were able to express myself candidly in a hotel lobby bar with a half-consumed beer in my hand, so you'll just ha ve to imagine what my version of Linus's infamous we don't break user space rant might sound like. I'm mellower, but it still wouldn't be pretty.) On a different but related note, I agree with Fred Templin and others. I sti ll think you're missing something. As it stands now, this document-- as you have said you plan to amend it-- can still be summarized as follows: [Section 2] IETF wrote standards for IPv6 f ragmentation and ICMPv6 path MTU discovery that many operators do not abide. [Section 3] IETF wrote standards for a raft of transport and application prot ocols that are broken as a result. [Section 4] Sad trombone. I would like to see Section 4 strengthened further, so it can be summarized l ike so: IETF will take the following steps to mend the damage. To be more specific, and to repeat myself again repeatedly and for redundancy, IETF shou ld promise-- among other things-- to do something in forthcoming drafts about the problems Fred Templin and I have been prodding the working group to deal with: the lack of PLPMTUD for tunnels like GRE, IPsec, et cetera, which need to carry encapsulated minimum MTU packets over paths where neither fragmenta tion nor RFC 1981 work. Fragmentation and/or RFC 1981 is essential to those protocols, they are broken wherever both are unavailable, while this draft ba sically capitulates and says, That's everywhere you care about. Sorry about that. Most importantly, there are no standard replacements, and no promises ever to produce standard replacements. What is to be done about that? I can write up my suggestion as a I-D. It provides the information stateless middleware needs to pass fragments. It also helps firewalls that decide they need to see the entire contents of packets by providing protection to their reassembly queues. -- james woodyatt j...@apple.com core os networking IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Meta-issues: On the deprecation of the fragmentation function
In message 51d6df54.9030...@si6networks.com, Fernando Gont writes: On 06/30/2013 10:42 PM, C. M. Heard wrote: Fernando So far (and without having read Ron's recent I-D -- shame on me), it Fernando looks like the main two reasons for deprecating the fragmentation Fernando function are: Fernando Fernando 1) The inability of middle-boxes to parse past the first XXX Fernandobytes of a packet Fernando Fernando 2) Unavailability of the connection-id (five-tuple) in the Fernandonon-first fragments. I disagree -- I think Mark Andrews got it (mostly) right in his message of Wed, 26 Jun 2013: Mark One needs to get the L4 information the firewall/loadbalancer uses in *each* fragment. Do you have this in IPv4? -- No. Then, why is it that special in v6? It's not special in IPv6. It is however easily *fixable* in IPv6 as the IPv6 packet format was designed to extended. Additionally IPv6 is the future and we are still very early into the lifetime of IPv6. If one wants to extend IPv4 to have similar capabilities go for it. I just think doing so will be wasted effort but I'm not going to stand in the way of someone that wants to do it. However, it won't help middle boxes that implement stateless packet filters. Indeed, such boxes have fundamental problems with non-first fragments irrespective of how many bytes of extension headers they can parse or whether there are sufficient length limits on the extension header chain that guarantee that the L4 header always appears in the first fragment. If you want to do stateless filtering, you should focus on filtering the first fragment. And have the end nodes (severs or whatever) implement sensible garbage collection for queued fragments (as it's usually the case). Which is what I do but it doesn't help with those that worry about those non initial fragments filling pipes and reassembly queues to the point where legitimate fragments that they want get discarded too soon. We need to be able to better classify non-initial fragments. At the moment we are classifying them to the L4 type (tcp, udp, icmp6, ipv6, ipv4, etc.) As I see it, the biggest meta-issue in this discussionis for the IPv6 WG is to decide out whether middle boxes that implement stateless packet filters with a default-deny policy will be a significant part of the landscape indefinitely, regardless of what the IETF says about their merits or lack thereof. Again: Why is this more special in v6 than in v4? -- You seem to be ignored the questions that I've asked. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: draft-bonica-6man-frag-deprecate
In message 00de01ce7385$15428a50$3fc79ef0$@tndh.net, Tony Hain writes: Antonios Atlasis wrote: ... Again, generally speaking (and not just for SEAL) RFC 5722 allows the abuse of its recommended policy for launching DoS attacks (a single overlapping fragment will result in discarding a whole datagram). On the contrary, if only the overlapping fragment is discarded, at least DoS will be slightly more difficult. DoS is more difficult, but packet hijack is easier. All an attacker needs to do is inject a set of fragments before the next one from the source to cause it to appear to be an overlap and rejected. Once the attacker can get the real fragments rejected as overlaps, the rest of the packet is filled with bogus attack fragments. Wouldn't it have been better to drop the whole datagram? DoS is a problem, but undetected malicious data is worse. Then add a cryptographic checksum of the original packet when fragmenting. 48 bits in a HBH should be enough. Tony IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: draft-bonica-6man-frag-deprecate
In message 1372377611.3215.141.camel@karl, Karl Auer writes: On Fri, 2013-06-28 at 09:31 +1000, Mark Andrews wrote: Then add a cryptographic checksum of the original packet when fragmenting. 48 bits in a HBH should be enough. Why HBH? Is that to prevent it being send in a fragment itself? And, um, I hate to suggest this, but isn't that sort of exactly what the AH header is for? I know, I know (covers head, ducks) I really don't care which header it is included in. If we could drop it to 32 bits we could just set the fragment id to the checksum and use one of the reserved bits to indicate that one should treat it as a checksum. My gut feel is that 32 bits is a little to small however. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
In message m24ncmaozs.wl%ra...@psg.com, Randy Bush writes: If it's a statement of fact, it shouldn't use RFC 2119 language. It should simply state the truth: Network operators might filter IPv6 fragments. s/might/do/ Which would be a totally mis-leading statement. Some network operators filter IPv6 fragments. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
In message 010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net, Tony Hain writes: Tore Anderson wrote: * George Michaelson One thing I *strongly* agree with: the sentence at 2.2: The effective MTU for IPv6 is 1280 bytes. This is looking compellingly awful, but true to me. I believe this is a gross exaggeration. I'm running 1500 bytes MTU on all the clients and servers in my network, and have yet to hear about significant trouble (there have been a few, but no more than what I get with IPv4 as well). So what happens over the next 10 years as there is a mix of 1500 4k systems? Or over the next 100 as the sizes continue to vary and routes flap across an array of link sizes? Yes pmtud sorts out part of that, but does tcp or the app need to become more dynamic about MSS changes during a connection? Why? Just so people that want to use the hammer of 'no fragments' are happy? Wouldn't it be better for everyone to actually solve the only real problem, and simply require the L4 protocol be in the first fragment? Short sighted myopia about a seriously outdated frame size should not drive decisions about long term deployment of an emerging protocol. If the L4 is in the first fragment, there are no other problems that need solving. If reassembly resources are a challenge for boxes specifically designed to do that, question why; but one could go further and require that the only fragment allowed to be smaller than 1280 is the last fragment. That would mitigate most of the resource-consumption-crafting nonsense. Tony One needs to get the L4 information the firewall/loadbalancer uses in *each* fragment. For UDP this is the source and destination ports. Create a new skipable hop-by-hop option that contains a copy of these values and add it along with a fragment header when fragmenting UDP packets. For TCP ensure that the IP layer informs the TCP layer if it would have to fragment the packet. i.e. don't send fragmented TCP packets. For ICMPv6 ??? For IPv4 if DF=0 fragment the Ipv4 packet to fit in inside 1280 IPv6 packets destination reassembles. For IPv4 if DF=1 return IPv4 PTB For XXX IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
In message 51ca2e75.7050...@gmail.com, Brian E Carpenter writes: On 26/06/2013 11:23, Randy Bush wrote: ... ron is actually deploying ipv6 in enterprises to see what his customers are seeing, eating his own dogfood. he did not field this draft for his amusement or to get his name on an rfc. The only times I've seen hard FAILs with apparently operational IPv6 sites were caused by MTU mismatch and TCP MSS negotiation failure, followed by silence which I assumed was due to fragmented packets being discarded. Yes, this is a real problem and doing nothing certainly isn't an option. We just need to be sure that the cure isn't worse than the illness. Named uses IPV6_USE_MIN_MTU=1 to avoid this. It should affect MSS negotiation but MacOS and FreeBSD are broken (bug fix submitted for FreeBSD). Mark Brian IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
In message 014201ce7208$1378c5f0$3a6a51d0$@tndh.net, Tony Hain writes: Mark Andrews wrote: One needs to get the L4 information the firewall/loadbalancer uses in *each* fragment. This is a manufactured requirement to allow devices that can't do a full reassembly to operate in under a policy of 'verify the entire packet'. Unfortunately, it doesn't even do that since it doesn't actually detect overlapping fragments if it is just verifying that the L4 information is the same. Many firewalls are just trying to ensure packets match the protocol, src address, src port, dest address, dest port tuple. They are not trying to protect from overlapping fragements. That said being able to filter out / forward without reassembly fragments that you are not interested in also reduces the number of fragments that need to be processed in the reassembly queues of the firewall itself when you are doing dpi of some of the packets. Load balancers just need to get over it, and use something more/other than the L4 in the hash. The FL was intended to provide a consistent value over the life of an L4 session, so why not use that instead of developing yet another new option? Wait,,, that doesn't exist in IPv4, so it can't be used because that would require learning something different... Flow labels aren't a solution for all problems. Yes, load balancers should make use of them. For UDP this is the source and destination ports. Create a new skipable hop- by-hop option that contains a copy of these values and add it along with a fragment header when fragmenting UDP packets. I have no problem with that concept, but why when there are other ways of accomplishing the task? Simply to mirror IPv4 is not a valid reason... It isn't just mirror IPv4. For TCP ensure that the IP layer informs the TCP layer if it would have to fragment the packet. i.e. don't send fragmented TCP packets. So TCP is never allowed to have a long-lived session ... No. It's send the equivalent of PTB back to the TCP layer and have it re-segment rather than fragment a badly sized segment it passed to the IP layer. You have a broken stack if you see a TCP fragment. Or routes are not allowed to flap. Which is it? You either tear down tcp and renegotiate mss every time routes flap to a path with a lower mtu, or you send fragments. It is easy to say the core is =1500 now, but what happens with a mix of 1500/4k/9k/32k/... over the life of IPv6? Are routes never allowed to flap with larger MTUs? Do you require every TCP implementation to do dynamic MSS, and try to get that deployed within a decade to two? For ICMPv6 ??? For IPv4 if DF=0 fragment the Ipv4 packet to fit in inside 1280 IPv6 packets destination reassembles. For IPv4 if DF=1 return IPv4 PTB For XXX -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
\) f...@cisco.com Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Message-ID: 34e0f96d-5ccb-4275-af64-e451b0036...@employees.org Content-Type: text/plain; charset=us-ascii I suppose I'm the contrarian +1. For me, this draft looks dangerous by proposing to deprecate fragmenta tion with only one-side observation. This draft does not give enough analysis on these existing fragmentation use cases, particularly these use cases the fragments within a single domain. On other side , only disallowing fragmentation to be used among domains ma y helpful to reduce the operational complex. this draft should help us tease out answers to the question: if we wanted to deprecate IPv6 fragmentation, could we? then when we know the collateral damage, it will be easier to answer the ot her question: should we deprecate IP layer fragmentation or not. cheers, Ole -- Message: 4 Date: Mon, 24 Jun 2013 17:50:36 + From: Templin, Fred L fred.l.temp...@boeing.com To: Fred Baker (fred) f...@cisco.com, Tore Anderson t...@fud.no Cc: ipv6@ietf.org 6man-wg ipv6@ietf.org Subject: RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt Message-ID: 2134f8430051b64f815c691a62d983180a9...@xch-blv-504.nw.nos.boeing.com Content-Type: text/plain; charset=us-ascii Hi Fred, -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Fred Baker (fred) Sent: Sunday, June 23, 2013 4:12 PM To: Tore Anderson Cc: ipv6@ietf.org 6man-wg Subject: Re: New Version Notification for draft-bonica-6man-frag- deprecate-00.txt On Jun 22, 2013, at 2:29 AM, Tore Anderson t...@fud.no wrote: - When a SIIT translator receives an IPv4 packet with DF=0 that would result in an IPv6 packet that would exceed the IPv6 link MTU, it will split the original packet into IPv6 fragments. It *could* fragment the IPv4 packet and send it in two unfragmented IPv6 packets. I cannot support your draft until it discusses or provides solutions for the above considerations. I'm in a similar case with respect to protocols above IPv6 (OSPF and NFS/UDP come quickly to mind) that depend on fragmentation to deal with the issue. I think the Robustness Principle tells us that such applications SHOULD figure out how to live with PMTU, but it also tells us that we can't deprecate fragmentation unless all known instances that depend on it have defined practical work-arounds. I suspect that this would imply the re-creation of the fragmentation feature in an intermediate protocol, That is essentially what SEAL does - it provides an intermediate-level segmentation and reassembly capability that avoids the pitfalls of IP fragmentation. which seems like a lot of work with little real gain. It's not that bad, and IMHO worth it. Thanks - Fred fred.l.temp...@boeing.com IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- ___ ipv6 mailing list ipv6@ietf.org https://www.ietf.org/mailman/listinfo/ipv6 End of ipv6 Digest, Vol 110, Issue 75 * IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
In message CAKr6gn2zu2n-pJMirG-seN5WX=evyquu9eqqlov-zf-rkq9...@mail.gmail.com , George Michaelson writes: --===4023034923616370839== Content-Type: multipart/alternative; boundary=047d7b86e55011538004dff06308 --047d7b86e55011538004dff06308 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 25, 2013 at 2:38 AM, Ronald Bonica rbon...@juniper.net wrote: ** ** I'd like to understand the basis of these assertions. I believe what I am seeing, on the edge, suggests there is in fact V6 fragmentation in both TCP and UDP. ** ** ** ** Hi George, ** ** It would be helpful if you could describe: ** ** **- **Where your observations are being made On our own web services (www.apnic.net, and an associated whois service which attracts more wide ranging traffic) On 'high in the tree' DNS servers for reverse DNS, including an NS of in-addr.arpa and ip6.arpa (note: dns transport is disjoint from the namespace being searched: we see queries over v6 transport to v4 domains, and to ccTLD we secondary) In a packet capture of 2400::/12 run in conjunction with Merit, as research into darknets. **- **What percentage of traffic is fragmented our own web: practically none. our own dns: 0.01%. in a sequence of 10 minute samples. consistently, I might add. the 2400::/12: around 0.25% to 1%. so more variable, but higher. **- **What kinds of packets are being fragmented our own DNS: port 53. little TCP. 2400::/12 capture. mostly port 53. TCP doesn't get captured in the darknet research. Its impossible to establish the end-to-end relationship. I am not sure I call up to 1% of something 'rare'. I'm not even sure I call 0.1% or 0.01% of something 'rare'. Otherwise, Since IPv6 adoption rates are at this class of deployment by end user, perhaps it also should be considered for deprecation.. It really would be helpful to understand your assertion about the rarity of IPv6 fragmentation. I want to understand how you got to this point of view on IPv6 frags. -George .58% of my IPv6 traffic in fragmented. Assuming that it is mostly UDP I get 14% of my IPv6 UDP traffic is fragmented. Most of that traffic is non local. I would assume most of the drops are due to PMTUD blocking the initial fragment but letting the tail fragment through as this machine is behind a tunnel. Mark ip6: 381915 total packets received 0 with size smaller than minimum 0 with data size data length 0 with bad options 0 with incorrect version number 2213 fragments received 0 fragments dropped (dup or out of space) 48 fragments dropped after timeout 0 fragments that exceeded limit 1077 packets reassembled ok 217810 packets for this host 0 packets forwarded 93958 packets not forwardable 0 redirects sent 297719 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 5031 output packets discarded due to no route 33 output datagrams fragmented 66 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 93924 multicast packets which we don't join Input histogram: hop by hop: 132 TCP: 202894 UDP: 15103 fragment: 2213 ICMP6: 161573 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
In message 8c48b86a895913448548e6d15da7553b921...@xmb-rcd-x09.cisco.com, Fred Baker (fred) writes: I suppose I'm the contrarian, but this draft gives me some heartburn surrounding the robustness principle. Yes, TCP MSS generally limits the use of fragmentation for IPv6. We don't have a counterpart to MSS for UDP, and othe rs have noted that OSPF etc may have issues. Thinking hypothetically, it would be unusual for OSPF to not be able to manage packet size via LSA choice, but s uppose I am on an interface that has a given MTU, and I have a single LSA that is larger than that MTU, perhaps a Router LSA on a wide fan-out unit. Deprecating the fragmentation capability forces each client of the network layer to create a means for fragmentation/segmentation. That might be some other protocol that essentially dupli cates what we're deprecating, or it could be something in which a router has to make enough routing instances of itself to split the Router LSA across them, or something like that. Personally, I think I would prefer a statement that says that the first fragment MUST contain the transport head er (which Fernando has been pushing), and encourages transports and applications to implement some variation on PMTU rather than depending on fragmentation, but not deprecating the capability. Or additionallty supply the information the firewall is looking for in a skipable hop-by-hop option. For UDP that would be the two ports. 6 to 8 extra octets per fragment. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
In message 51c7a69f.40...@dougbarton.us, Doug Barton writes:
Given that larger and faster pipes are becoming more common, and given
that we know that larger packet sizes make for more efficient
utilization of those pipes, IMO it's a really bad idea to give up the
fight at this early stage in IPv6 deployment.
Until there is dramatic evidence to the contrary it seems to me that
it's still worthwhile to push for making the protocol work as designed.
Doug
For DNS PMTUD is just too slow (TCP) or doesn't work (UDP) as the
servers don't keep query state to resend replies on ICMPv6 frag
required and client retries are just too slow to trigger the resend.
This is why I pushed for a way to say fragment at 1280 back in
'98[1] which became IPv6_USE_MIN_MTU[2].
A recursive server has around 3 seconds to do a DNS lookup before
the client gives up. In that time it has to talk to multiple
servers. Deal with dead servers. Deal with packet loss due to
congestion. Deal with broken servers that don't respond. Deal
with PMTUD. Deal with broken firewalls that don't pass fragments.
PMTUD can be eliminated by setting IPv6_USE_MIN_MTU. This should
result in UDP fragments and TCP segments that don't get blocked due
to IP packet size. Some TCP stacks are broken as IPv6_USE_MIN_MTU
is ignored when they do their MSS negotiation.
As far as I can see the main reason fragmentation becomes a issue
is that firewalls and load balancers can't determine what to do
with a fragment as some information from the L4 header is missing.
If we supply that information in every fragment as a hop-by-hop
option{s} most of the problems are addressed.
You still have some firewalls that want to do deep inspection of
the packet but even then they could reassemble after filtering based
on the hop-by-hop option{s} which would provide some protection to
the reassembly queues on the firewall.
I also don't see what the deep inspection of UDP/DNS packets is
trying to accomplish when the same firewall passes TCP/DNS messages
without reassembling them. If you are a malicious server you would
just set TC=1 and attack the client over TCP. Yes, most clients
do correctly handle TC=1.
Mark
[1] https://datatracker.ietf.org/doc/draft-ietf-ipngwg-bsd-frag/
[2] http://tools.ietf.org/html/rfc3542
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
In message 2cf4cb03e2aa464ba0982ec92a02ce2509f86...@by2prd0512mb653.namprd05.prod.outlook.com, Ronald Bonica wri tes: -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Friday, June 21, 2013 4:53 PM To: Ronald Bonica Cc: Ray Hunter; ipv6@ietf.org 6man-wg Subject: Re: FW: New Version Notification for draft-bonica-6man-frag- deprecate-00.txt On 22/06/2013 07:53, Ronald Bonica wrote: I don't 100% agree. In the case that PMTUD is broken, there'd be nothing to stop a current DNSSEC implementation from always assuming a default path MTU of 1280, without awaiting confirmation from PMTUD, and fragmenting the UDP packet pre-emptively [assuming fragmentation was not equally broken along the path as ICMP PTB was]. Do any implementations actually do this? If they do, how well are they working, today? Does it matter? Hi Brian, I think that it does. If a DNSSEC implantation fragments every packet larger than 1280 bytes, regardless of whet her that packet needs to be fragmented: - it ignores the advice of RFC 2460 and RFC 5405 - it doesn't work very well today, because so many operators filter its fragmented output AFAIKS, there are two ways to make this application work better: - make people stop filtering IPv6 fragments - change the implementation's behavior Given that the former is impossible, it seems that the later is required. Ron Named has set IPv6_USE_MIN_MTU for years for UDP. There are plenty of paths that have path mtu issues but not fragmentation issues (tunnels). Many firewalls allow fragments out but not icmp back in. Named currently sets IPv6_USE_MIN_MTU for TCP. Mark IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [v6ops] [6MAN] Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)
In message 6fae3df4-b5b4-4f21-9098-761523745...@kumari.net, Warren Kumari writes: On Jun 12, 2013, at 2:44 PM, Robert Elz k...@munnari.oz.au wrote: Date:Wed, 12 Jun 2013 19:49:08 +0200 From:Gert Doering g...@space.net Message-ID: 20130612174908.gt2...@space.net = | Loop back to about 50 messages earlier in this thread, = I don't generally read this list (any more) - just happened to see the past hour's worth of messages, so I have no idea what was 50 messages earlier, but ... = | We're not talking ivory tower theoretical routers. We're talking about | devices that can stand the heat out there, like be able to apply diffe= rent | rate limiting classes to incoming BGP SYNs from trusted networks, and to | ICMP packets from the world. This MUST be done by the hardware, and it | MUST be able to look at *Layer 4* information. = If that's the issue, then the routers should just be treating any packet = with a frag header like dirt. = You mean like: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 ? Seeing as I filter on routers (which don't do reassembly) and I want to kno= w what's actually in the packets I let into my network, they just get dropp= ed on the floor. Ain't nobody noticed, so, if it ain't broke=85 W Don't take lack of complaints as nobody noticed. If you want complaints then nameserver vendors can remove the code which tries you handle your broken routers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Limiting the size of the IPv6 header chain (draft-ietf-6man-oversized-header-chain)
The obvious limit is no re-assembly required to find the L4 header. As for fragments not containing enough information create a new fragement header code and copy more of the existing headers. Use ICMPv6 Parameter Problem as a signal to switch back to the old fragmentation header. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Next steps for draft-gont-6man-predictable-fragment-id
In message fb329d818c7cab438f0c7dd772ea102506246...@tk5ex14mbxc252.redmond.cor p.microsoft.com, Dmitry Anipko writes: In such an attack, is the attacker on the path between the victim and the ser ver? If yes, there are more efficient ways how they can DoS the victim. If no , how does the attacker know which of the billions hosts on the Internet will be talking to this DNS server in the next second (in order to send packets w ith fake source address to that particular victim host)? Separately from that, how often network operators deploy egress filtering, th at drops packets from malicious hosts sent with fake source addresses? Well we know enough of them don't for reflection amplicifation attacks to be a be a problem. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
draft-ietf-6man-addr-select-opt
prefix: A variable-length field containing an IP address or the prefix of an IP address. An IPv4-mapped address [RFC4291] must be used to represent an IPv4 address as a prefix value. The prefix should be left aligned, big-endian, and zero padded on the right up to the next octet boundary. So the length of this field should be between 0 and 16 bytes is ambigious on the encoding of 2002:1234:8734::/64 is it: 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00 or 40:20:02:12:34:87:34:00:00 or 40:20:02:12:34:87:34:00 or 40:20:02:12:34:87:34 All appear to be legal. It would be cleaner if the floor((prefix-len+7)/8) gave the number of octets in the prefix field. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-6man-addr-select-opt
In message b9fc989e-a7cf-484e-a19c-e8ee58316...@consultant.com, Cutler James R writes: On Feb 5, 2013, at 10:12 PM, Mark Andrews ma...@isc.org wrote: prefix: A variable-length field containing an IP address or the prefix of an IP address. An IPv4-mapped address [RFC4291] = must be used to represent an IPv4 address as a prefix value. The prefix should be left aligned, big-endian, and zero padded = on the right up to the next octet boundary. So the length of = this field should be between 0 and 16 bytes =20 is ambigious on the encoding of 2002:1234:8734::/64 =20 is it: 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00:00 or 40:20:02:12:34:87:34:00:00:00 or 40:20:02:12:34:87:34:00:00 or 40:20:02:12:34:87:34:00 or 40:20:02:12:34:87:34 =20 All appear to be legal. It would be cleaner if the floor((prefix-len+7)/8) gave the number of octets in the prefix field. Mark, You have me confused here. /64 defines a prefix length of 64 bits, = exactly 8 octets. Octet for Octet, 20:02:12:34:87:34:00:00 is = unambiguously correct and in accordance with the definition cited. = Please explain where the leading 40 originates. The 40 was the prefix length octet (0x40 == 64). Sorry for not being clear on that. The sub-option has a length field which means that you can append zeros up to the defined maximum (16). As it is a zero padded field you can also theoretically remove trailing zeros without loss of information. Nothing in the definition says that you can't do that. prefix-len: An 8-bit unsigned integer; the number of leading bits in the prefix that are valid. The value ranges from 0 to 128. Mark James R. Cutler james.cut...@consultant.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [Geopriv] Adding GPS location to IPv6 header
but there is no rule that triggers configuration change based on geo-location. - What do you think? Author/Contact Information: Ammar J. Salih Baghdad, Iraq Phone: +964 770 533 0306 Email: ammar.alsa...@gmail.com IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 The ignorance of how to use new knowledge stockpiles exponentially. - Marshall McLuhan ___ Geopriv mailing list geop...@ietf.org https://www.ietf.org/mailman/listinfo/geopriv ___ Geopriv mailing list geop...@ietf.org https://www.ietf.org/mailman/listinfo/geopriv ___ Geopriv mailing list geop...@ietf.org https://www.ietf.org/mailman/listinfo/geopriv IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions
In message 50a23f5b.9070...@bfk.de, Hannes Frederic Sowa writes: On 11/13/2012 02:34 AM, Fernando Gont wrote: * If IPV6_USE_MIN_MTU means use an MTU of 1280 bytes (as opposed to use an MTU of *at most* 1280 bytes) then IPV6_USE_MIN_MTU might still result in fragmentation. If, OTOH, IPV6_USE_MIN_MTU means use an MTU of at most 1280 bytes, then fragmentation might be prevented by signaling any received ICMPv6 PTB to the upper layer, such that the TCP SMSS is reduced acordngly, and hence fragmentation is avoided. Is the second case really possible? MSS is defined to be always derived from the MTU. As the IPv6 minimum MTU is 1280 I see no way how the MSS could sink below 1280-40-20 bytes. While the MSS may be that, the segment size will change depending apon which TCP option are being sent. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions
In message 50a111fb.2060...@bfk.de, Hannes Frederic Sowa writes: On 11/07/2012 02:30 AM, Mark Andrews wrote: Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? As I have not read otherwise I would treat IPV6_USE_MIN_MTU as transport-agnostic. The problem is that there are at least 2 OS's with TCP layers that do not use IPV6_USE_MIN_MTU when calculating the TCP segment size to send. I would have thought that this would have been obvious to do. Do we need update RFC3542 to say that IPV6_USE_MIN_MTU is to be used when calculating the TCP segment size? The usage of IPV6_DONTFRAG is only specified on UDP and raw sockets (see RFC3542 11.2). Which is short sighted. There is no reason not to apply it to all transports as all transports have to handle PTB and this is just a locally generated PTB. And while we are talking about RFC3542 how to we get POSIX updated to include the advanced half of the API as it is a pain in the butt for application developers. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions
Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? Both options were set on the socket with the resulting packet trace. For reference the stack was: OS X 10.8.2 (12C60) Mark 12:24:05.521331 IP6 2001:470:1f00:820:6233:4bff:fe01:7585 2001:470:1f00:820:218:f3ff:feba:9a37: frag (0|1232) 53 49203: Flags [.], ack 31, win 8209, options [nop,nop,TS val 986656829 ecr 3464680466], length 120012159*- 194/0/0 SOA, RRSIG, RRSIG, DNSKEY, DNSKEY, RRSIG, NSEC, RRSIG, MX bsdi.dv.isc.org. 0, RRSIG, NS bsdi1.dv.isc.org., NS drugs.dv.isc.org., RRSIG, RRSIG[|domain] 12:24:05.521582 IP6 2001:470:1f00:820:6233:4bff:fe01:7585 2001:470:1f00:820:218:f3ff:feba:9a37: frag (1232|228) 12:24:05.522636 IP6 2001:470:1f00:820:6233:4bff:fe01:7585 2001:470:1f00:820:218:f3ff:feba:9a37: frag (0|1232) 53 49203: Flags [.], ack 31, win 8209, options [nop,nop,TS val 986656829 ecr 3464680466], length 120020864 updateD [b23=0x50c3] [20596a] [50814q] [43695n] [14436au] Type35395 (Class 51553)? dv.isc.org.[|domain] 12:24:05.522887 IP6 2001:470:1f00:820:6233:4bff:fe01:7585 2001:470:1f00:820:218:f3ff:feba:9a37: frag (1232|228) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: IPV6_USE_MIN_MTU and IPV6_DONT_FRAG questions
In message 1352259190.4281.104.camel@karl, Karl Auer writes: On Wed, 2012-11-07 at 12:30 +1100, Mark Andrews wrote: Should setting IPV6_USE_MIN_MTU to one (1) result in fragmented TCP packets? Should setting IPV6_DONTFRAG to one (1) work on TCP sockets? [...] Both options were set on the socket with the resulting packet trace. Speaking from a position of ignorance here, but my understanding is that if you use the first, the second is ignored, which is what seems to be happening in that trace. I also believe that the second does not apply to TCP. I'd expect that if you use the first then PMTUD should be disabled and the stack will fragment larger packets normally and send atomic fragments if the whole thing (plus fragment header) fits in a single fragment. If the implementation doesn't believe in atomic fragments then it will fragment only packets too large to fit in 1280 bytes and will send smaller ones without a fragment header. I'd expect the TCP layer to look at the IP layer MTU and adjust its segment size to match. That said, I reiterate my ignorance. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-6man-uri-zoneid-02.txt
In message d41807cf-b7f5-4770-8fb5-f0630aa4f...@apple.com, Stuart Cheshire wr ites: On 16 Jul, 2012, at 20:50, Mark Andrews wrote: Stuart, your mail client botched the Content-type line generation. You may want to report it. Content-type: image/png; x-unix-mode=0644; name=Whatis#39; ?.png= Content-transfer-encoding: base64 Content-disposition: inline; filename=What is #39; ?.png Mark Mark, your tone sounds very confident that you're absolutely certain that you know exactly what botched what, and whose fault it is. I'll reserve judgement until I actually know what happened, but what I can tell you is this: Viewing the outgoing TCP packets with tcpflow, this is what my mail client sends on-the-wire to the SMTP relay: Content-Transfer-Encoding: base64 Content-Type: image/png; x-unix-mode=0644; name=What is #39; ?.png Content-Disposition: inline; filename=What is #39; ?.png Which isn't a syntactically valid Content-Type header (RFC 1341). By the time you received the email, Mark, it had been rewritten to the form you showed. As to what intermediary (or intermediaries) contributed to that rewriting, I do not yet know. It may have been re-written but Garbage In - Garbage Out. It's ironic that this problem occurs in the midst of a discussion of the problems of escaping and message framing. The reality seems to be that unless we keep things supremely simple, we can't hope to have all programmers get it right in all cases. If there's exactly one valid form for a string, then maybe we can hope to have that implemented properly. When there are different representations of the same string in different contexts, the probability of everyone getting it right in all contexts pretty much approaches zero. It was slightly ironic. Slightly off-topic, I'm told that at least some mail clients truncated my original email at the line unintentionally leaked through into the user interface. As composed on my Mac, there was some introductory text, then two images, then the bulk of the text, as it appears in the archive: http://www.ietf.org/mail-archive/web/ipv6/current/msg16128.html Apparently some mail clients turned the second chunk of body text into an attachment. I'm curious as to how widespread this issue is -- I might have to be more careful about where I put images in my email messages in the future. Could people send me a quick private email saying what mail client they use and whether it: 1. Showed the entire message as I composed it with the two images displayed in-line (like the archive). 2. Showed the entire text of the message, but with the two images as attachments (Gmail shows it this way). 3. Showed only the first five paragraphs of text, with the two images and remaining text as attachments. I'll summarize results to the list. Stuart Cheshire -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: RFC2460 violation of RFC1122
In message e1829b60731d1740bb7a0626b4faf0a65d8f4c8...@xch-nw-01v.nw.nos.boeing .com, Templin, Fred L writes: Section 5 of RFC2460 states: In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. RFC2460 therefore requires the IPv4 destination to be able to reassemble at least 1280 bytes minus 28 (since the translation from an IPv6 header plus fragment header to an IPv4 header incurs a 28 byte size reduction). However, section 3.3.2 of RFC1122 states: We designate the largest datagram size that can be reassembled by EMTU_R (Effective MTU to receive); this is sometimes called the reassembly buffer size. EMTU_R MUST be greater than or equal to 576, SHOULD be either configurable or indefinite, and SHOULD be greater than or equal to the MTU of the connected network(s). By assuming an EMTU_R of greater than 576 bytes, RFC2460 is therefore in violation of RFC1122, which could lead to communication failures. How do we reconcile this? You live with it. Nobody has said that IPv6 to IPv4 translation will work in all circumstances. Thanks - Fred fred.l.temp...@boeing.com IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Yes, I know this is the wrong mailing list
In message 4ffccd9a.10...@m5p.com, George Mitchell writes: So I was trying to browse the list of IETF mailing lists at www.ietf.org to see who might be interested in my failures to browse sites like yahoo.com and netflix.com following the onset of World IPv6 Day. Except that I can't browse www.ietf.org either. It did work previously. I have a packet capture of the failing telnet www.ietf.org 80 session, if anyone is interested. It looks fine and proper, all the expected SYNs and ACKs as I sent my HTTP request, except for the failure to return any HTTP response. I'm running FreeBSD 9.0-STABLE. 8.2-STABLE also fails the same way. No doubt you can reach www.m5p.com over IPv6; it's been working for years. Would one of you be able to tell me which mailing should I be using? My apologies for the inappropriate message. -- George Mitchell IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 This sort of failure is usually a PMTUD failure. If you are using a tunnel you need to ensure that your tunnel provider sends back PTB's. The IETF servers do see the PTB's. www.ietf.org does work over tunnels. You can test this theory by lowering the local mtu using route change -inet6 :: -mtu 1280 (from memory). This will change the advertised mss from 1440. route -n get -inet6 :: will show you the current values. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Yes, I know this is the wrong mailing list
In message 4ffcdf5c.80...@m5p.com, George Mitchell writes: On 07/10/12 21:35, Mark Andrews wrote: In message 4ffccd9a.10...@m5p.com, George Mitchell writes: So I was trying to browse the list of IETF mailing lists at www.ietf.org to see who might be interested in my failures to browse sites like yahoo.com and netflix.com following the onset of World IPv6 Day. Except that I can't browse www.ietf.org either. It did work previously. I have a packet capture of the failing telnet www.ietf.org 80 session, if anyone is interested. It looks fine and proper, all the expected SYNs and ACKs as I sent my HTTP request, except for the failure to return any HTTP response. I'm running FreeBSD 9.0-STABLE. 8.2-STABLE also fails the same way. No doubt you can reach www.m5p.com over IPv6; it's been working for years. Would one of you be able to tell me which mailing should I be using? My apologies for the inappropriate message. -- George Mitchell IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 This sort of failure is usually a PMTUD failure. If you are using a tunnel you need to ensure that your tunnel provider sends back PTB's. The IETF servers do see the PTB's. www.ietf.org does work over tunnels. You can test this theory by lowering the local mtu using route change -inet6 :: -mtu 1280 (from memory). This will change the advertised mss from 1440. route -n get -inet6 :: will show you the current values. And so I don't have to do it repeatedly, I can change /etc/rc.conf from: ipv6_defaultrouter=2001:418:3fd::fd to: ipv6_defaultrouter=2001:418:3fd::fd -mtu 1280 I appreciate all the help! -- George You really should talk to your tunnel provider and get this fixed as this only helps TCP connections. It does not help UDP based protocols. Once your tunnel provider has fixed the tunnel ingress to correctly sent PTB's you will then be in a position to report broken web sites. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: RFC 5952, the errata, and real-world usage
In message m2pq9msdva.wl%ra...@psg.com, Randy Bush writes: Next thing you know, I'm going along based on this recollection, I look up RFC 5952, and I notice there's now an errata associated with it. Would that errata be about some grammatical minutiae? Nope. It's specifically to switch back to upper case hex representation! there is a lesson here randy IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 It is only Reported. I would say that it needs to be moved to Rejected. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
There are claims of ambiguity over what is a link-local address
See the nanog thread starting here: http://mailman.nanog.org/pipermail/nanog/2012-May/048079.html -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: 3484bis and privacy addresses
In message 4f74f78f.1020...@dougbarton.us, Doug Barton writes: Also, if you're on a home network, it doesn't matter what the bottom 64 bits are, your network prefix is enough information for the bad guys to use as ICBM targeting coordinates. And if we want to address home networks then we need a way to signal that we want both stable and temporary prefixes with PD and a way to differentiate them when advertising them via RA. DHCPv6 already has IA_NA and IA_TA. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
In message 006e01cd0668$898f0770$9cad1650$@la...@eurid.eu, Marc Lampo write s: Hello, I understand what you are writing, but is this the right way ? Yes. It was always intended that this be updatable network wide. http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09 The address selection table is, as far as I understand, statically defined - not dynamically configurable (SLAAC or DHCPv6). So, the suggestion is to adapt the table on every node of the organisation. Yep. DHCP does this sort of thing very well. In other words, every node in the organisation is somehow - via the address selection table - aware of the organisations network topology (VPN's and so). Is this desired ? Sure, why not? Lots of equipment won't need to know it but they are all capable of processing. Kind regards, Marc Lampo -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
In message 00f801cd05a2$abfce190$03f6a4b0$@la...@eurid.eu, Marc Lampo write s: Hello, +1 for Brian's statement : ULA within same /48, prefer ULA. For ULA not within same /48 : Please do not forget VPN ! In the IPv4 world, numerous devices, with private address space, Communicate through site-to-site VPN's. I'd assume this is equivalent to ULA not in same /48. How could an end-device decide whether or not VPN is in place ? Wouldn't it be preferable to let name resolving decide which address to return to a client ? And if name resolving returns ULA, let end-device use ULA as well. (If there is no VPN in place, it would be a configuration error in the name resolving infrastructure) That way, network admins decide centrally, trough name resolving, how some party is can be reached. Any errors there would be name resolving which can, through DNS, be centrally solved. As opposed to some smart algorithm on end nodes that mistakingly choses the wrong address (and requiring some update on all of them ...) Kind regards, Marc Lampo Are connecting a node or a net over the VPN? For a node this is a non-issue as the VPN's interface will be in one ULA and home net in the other ULA. The node is a site boundary. If you are connecting a net then you can do PD request(s) and advertise the returned prefixes. If the upstream starts to run out of prefixes they just generate a additional ULA prefix and number all the servers from it. Different VPN use different ULA but all can reach the central servers. By the time a organisation reaches this level of complexity they are a small ISP in their own right and should be able to get /32. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
In message 01f401cd05dc$20914df0$61b3e9d0$@la...@eurid.eu, Marc Lampo write s: Allow me to clarify with an example. In my IP(v4) experience, I have a customer with offices over multiple Continents - private address space in use everywhere - site-to-site VPN's (== connecting networks) connect the offices. If I map to IPv6 this might be one /48 ULA range; Some networks in central HQ, others remotely, behind site-to-site VPN. -- if one end-node in one network wants to reach another, in another network, its traffic must travel through the VPN. Please observe that using public addresses (not using ULA) might do away with address selection challenges but would imply that networks on all continents will have to be renumbered if the central HQ changes ISP (and hence : public IPv6 addresses). Something I'd like to avoid ... Kind regards, Marc Lampo Well with a single ULA you have 65536 /64 sized networks to use where ever you want. You have ULA:/56 in Paris, ULA:0100/55 in New York. You don't have to keep things bit aligned but it helps. 65536 prefixes isn't a lot of routing information. Think of it in IPv4 terms as 10/8 and you are handing out /24 for each subnet except you know you won't need more than /24 ever. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
In message 20120319220801.964e91ead...@drugs.dv.isc.org, Mark Andrews writes: In message 01f401cd05dc$20914df0$61b3e9d0$@la...@eurid.eu, Marc Lampo wri te s: Allow me to clarify with an example. In my IP(v4) experience, I have a customer with offices over multiple Continents - private address space in use everywhere - site-to-site VPN's (== connecting networks) connect the offices. If I map to IPv6 this might be one /48 ULA range; Some networks in central HQ, others remotely, behind site-to-site VPN. -- if one end-node in one network wants to reach another, in another network, its traffic must travel through the VPN. Please observe that using public addresses (not using ULA) might do away with address selection challenges but would imply that networks on all continents will have to be renumbered if the central HQ changes ISP (and hence : public IPv6 addresses). Something I'd like to avoid ... Kind regards, Marc Lampo Well with a single ULA you have 65536 /64 sized networks to use where ever you want. You have ULA:/56 in Paris, ULA:0100/55 in New York. You don't have to keep things bit aligned but it helps. 65536 prefixes isn't a lot of routing information. Think of it in IPv4 terms as 10/8 and you are handing out /24 for each subnet except you know you won't need more than /24 ever. Alternatively you can give each site its own ULA and you use non default address selection rules. Remember we are talking about the default rules here. There are billions of more homes than there are businesses. They would use rules like the follow which give all the sites a common label: ::1 50 0 ULA1:/48 45 100 ULA2:/48 45 100 ULA3:/48 45 100 ::/0 40 1 2002:: 30 2 fc00:: 03 Whereas the default rules generate a table like if it was multi-homed to three sites: ::1 50 0 ULA1:/48 45 4 ULA2:/48 45 5 ULA3:/48 45 6 ::/0 40 1 2002:: 30 2 fc00:: 03 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
In message 4f63896e.10...@gmail.com, Brian E Carpenter writes: On 2012-03-16 23:30, Arifumi Matsumoto wrote: ... Rather, my question was about the design choice. Regarding the design of ULA and how to use the ULA, can we agree that ULA-to-ULA communication within the same /48 prefix is not always preferred over other communications using IPv4 or IPv6 global addresses ? I would expect it to be preferred as a result of longest match; I would not expect it to be a special case in the default policy for global scope addresses, if that is the question. Second, when a user configures his policy table, the configured table is overwrit ten by this implementation dependent policy injection behavior ? Can the user suppress this behavior of policy injection ? This issue should arise also when a policy distributing mechanism is read y. Good questions. Do you have suggested answers to those questions? I might throw out a strawman of: Any automatic rows added by the implementation as a result of address acquisition MUST NOT override a row for the same prefix configured via other means. That is, rows can be added but never updated automatically. An implementation SHOULD provide a means for an administrator to disable automatic row additions. My suggested answer for this was to use macros, which can be added/deleted by a user, and interpreted as the actual prefix attached to the hosts. That's an implementation method. I think Dave's proposed rule is correct. Brian What I see missing is a way for a node to know what the site boundaries are with respect to address selection. Adding a site prefix length to RA Prefix Information would provide a 99.99% solution to this. If the Site Prefix field is non-zero it is valid. e.g. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length | Prefix Length |L|A| Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Site Prefix | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | +Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
In message 9b57c850bb53634cacec56ef4853ff653b4a5...@tk5ex14mbxw603.wingroup.wi ndeploy.ntdev.microsoft.com, Dave Thaler writes: See http://tools.ietf.org/html/draft-ietf-ipngwg-site-prefixes-05 -Dave Essentially the same thing with a wasted bit. No site is the world so you don't need the S bit if you make valid site prefix lengths 1..128. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: ULA macro in the policy table Re: -06 candidate
In message 120e3724-7356-45f1-b70c-0b3081d8e...@nttv6.net, Arifumi Matsumoto writes: Hi, On 2012/01/23, at 16:09, Mark Andrews wrote: In message 43f32baa-c3cb-4214-bce7-b1cd75ec5...@nttv6.net, Arifumi Matsum oto writes: Mark, thank you for your comment. As you mention it, it should be less harmful to give the whole ULA block a lower precedence value, if we assume ULA leakages will happen here and there by DNS mis-configurations, address information exchange in P2P applications, and so on. Regarding communication between ULAs, such a network that really wants to make use of multiple ULA blocks should have a way of controlling address selection behavior of their hosts, such as policy table configuration and DNS configuration. The question is whether we can accept the appearance of macro in the policy table. PrefixPrecedence Label ::1/128 60 0 YOUR ULA:/4850 1 You also want the labels for each ULA/48 to be seperate. YOUR ULA:/4850 # Do we need to have different labels for ULAs ? If ULAs are assigned to a host, the host can choose an appropriate source ULA address because of the longest match rule. That may be enough. ::/0 40 2 :::0:0/96 30 3 2002::/16 20 4 2001::/32 10 5 fc00::/7 5 6 ::/96 110 fec0::/10 111 3ffe::/16 112 I assume the line of YOUR ULA will be interpreted as a line or lines of ULA prefix(es) that is attached to interface(s). Another point is that a host has to maintain the ULA line in responses to addition and deletion of the addresses. Another possibility is just the de-pref of the whole ULA block. PrefixPrecedence Label ::1/128 60 0 ::/0 40 2 :::0:0/96 30 3 2002::/16 20 4 2001::/32 10 5 fc00::/7 5 6 ::/96 110 fec0::/10 111 3ffe::/16 112 In this case, the problem Mark pointed out will not happen, but ULA will not be preferred over IPv4 and IPv6 global addresses. Do we really prefer ULA over these addresses ? Yes. Think Homenet where you want *internal* connections to use ULA rather than PA addresses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: ULA macro in the policy table Re: -06 candidate
In message 43f32baa-c3cb-4214-bce7-b1cd75ec5...@nttv6.net, Arifumi Matsumoto writes: Mark, thank you for your comment. As you mention it, it should be less harmful to give the whole ULA block a lower precedence value, if we assume ULA leakages will happen here and there by DNS mis-configurations, address information exchange in P2P applications, and so on. Regarding communication between ULAs, such a network that really wants to make use of multiple ULA blocks should have a way of controlling address selection behavior of their hosts, such as policy table configuration and DNS configuration. The question is whether we can accept the appearance of macro in the policy table. PrefixPrecedence Label ::1/128 60 0 YOUR ULA:/4850 1 You also want the labels for each ULA/48 to be seperate. YOUR ULA:/4850 # ::/0 40 2 :::0:0/96 30 3 2002::/16 20 4 2001::/32 10 5 fc00::/7 5 6 ::/96 110 fec0::/10 111 3ffe::/16 112 I assume the line of YOUR ULA will be interpreted as a line or lines of ULA prefix(es) that is attached to interface(s). Another point is that a host has to maintain the ULA line in responses to addition and deletion of the addresses. Regards, On 2012/01/18, at 7:26, Mark Andrews wrote: ULA need to be de-preferenced except for the local ULA prefixes. Below is what I use in FreeBSD 8. It keeps local traffic using fd92:7065:b8e::/48 rather than using the PA address. If you learn a ULA destination address that is not local YOU DO NOT WANT TO USE IT by default when you have another choice. What you do want is for a interface when it learns a ULA address to add the corresponding /48 prefix with a given precedence and a unique label to the table if the prefix does not exist. And appropriate cleaning be done when no more interfaces exist in the /48. This may require a manual tag on table entries. Mark more /etc/ip6addrctl.conf #Prefix Prec Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 :::0.0.0.0/96 35 4 fd92:7065:b8e::/4845 5 fc00::/7 5 6 ifconfig nfe0 inet6 nfe0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=82008VLAN_MTU,WOL_MAGIC,LINKSTATE inet6 fe80::218:f3ff:feba:9a37%nfe0 prefixlen 64 scopeid 0x5 inet6 fd92:7065:b8e:0:218:f3ff:feba:9a37 prefixlen 64 autoconf inet6 2001:470:1f00:820:218:f3ff:feba:9a37 prefixlen 64 autoconf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arif...@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: -06 candidate
ULA need to be de-preferenced except for the local ULA prefixes. Below is what I use in FreeBSD 8. It keeps local traffic using fd92:7065:b8e::/48 rather than using the PA address. If you learn a ULA destination address that is not local YOU DO NOT WANT TO USE IT by default when you have another choice. What you do want is for a interface when it learns a ULA address to add the corresponding /48 prefix with a given precedence and a unique label to the table if the prefix does not exist. And appropriate cleaning be done when no more interfaces exist in the /48. This may require a manual tag on table entries. Mark more /etc/ip6addrctl.conf #Prefix Prec Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 :::0.0.0.0/96 35 4 fd92:7065:b8e::/4845 5 fc00::/7 5 6 ifconfig nfe0 inet6 nfe0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=82008VLAN_MTU,WOL_MAGIC,LINKSTATE inet6 fe80::218:f3ff:feba:9a37%nfe0 prefixlen 64 scopeid 0x5 inet6 fd92:7065:b8e:0:218:f3ff:feba:9a37 prefixlen 64 autoconf inet6 2001:470:1f00:820:218:f3ff:feba:9a37 prefixlen 64 autoconf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: -06 candidate
In message 4f1633d7.7050...@gmail.com, Brian E Carpenter writes: On 2012-01-18 11:26, Mark Andrews wrote: ULA need to be de-preferenced except for the local ULA prefixes. Below is what I use in FreeBSD 8. It keeps local traffic using fd92:7065:b8e::/48 rather than using the PA address. If you learn a ULA destination address that is not local YOU DO NOT WANT TO USE IT by default when you have another choice. Not true if you have a VPN link to a business partner and you want your traffic to that partner to use the ULA, which is routed via the VPN, rather than a GUA that is routed via the Internet. Which doesn't fall under a *default* policy. You would add the partner's /48 to custom table and distribute it rather than use the default. Not true if an enterprise uses multiple ULA prefixes internally for some reason. Again this doesn't fall under a *default* policy. These cases will need explicit policy table entries if the default is de-pref as you suggest. And any ULA address that leaks, and they will, will cause back holes to appear, similar to the way broken 6to4 does. Fast retries, similar to HE, will help somewhat but sensible defaults and knowing when to override them work even better. Brian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Fragmentation-related security issues
In message 4f06ba27.3030...@dougbarton.us, Doug Barton writes: On 01/05/2012 14:54, Fernando Gont wrote: On 01/05/2012 07:45 AM, Florian Weimer wrote: Steinar wrote that atomic fragments break FreeBSD 7.4 (and there might be others, of course). Not sending them breaks important transition technology. Looks like FreeBSD should patch. :-) FYI, FreeBSD 7.4 is the last release of the 7.x branch, and was released almost a year ago. It's scheduled to EOL in a little more than a year. It would be much more interesting to know if the bug is still present in the stable/8 branch (which will see at least one more release) or more The bug is still in 8 stable: http://svnweb.freebsd.org/base/stable/8/sys/netinet/ipfw/ip_fw2.c?view=log importantly, in the about-to-be-released 9.0. It's fixed in 9 stable. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Fragmentation-related security issues
In message fa928b87-a687-4e48-a3f1-33e170142...@puck.nether.net, Jared Mauch writes: On Jan 4, 2012, at 9:55 PM, Brian E Carpenter wrote: The point is that paranoid firewalls will turn this into an arms race - if they are paranoid enough to block ICMP PTB, which apparently many are, why wouldn't they block any other signalling mechanism - especially a new one? That's why RFC 4821 describes MTU probing hidden in the transport layer, where hopefully firewalls would let it be. You will probably look in vain for widely deployed versions of RFC 4821. We will not win a discussion with people who fail to understand how the technology actually works vs their concept of it. I'm waiting for the likely millions of users to have trouble when dns more often requires TCP transport for some queries/responses. I see the side-effects of this in my name server logs daily for people not doing EDNS and who can't handle udp packets past 512. Jan 5 07:35:55 puck named[26179]: fldsmtpe02.verizon.com/A: changed rcode: s etting NOEDNS flag in adb cache for '192.76.85.133#53' That one isn't outside the spec. The server answers EDNS queries, it's just a old (RFC 1035), server. What is outside the spec in silently dropping queries if you see something you don't understand. RFC 1035 has a error code (FORMERR) for that and it should be returned. What is unconscionable, is firewall vendor shipping products in 2012 which don't handle protocol changes from 1999. EDNS is designed to interoperate with RFC 1035 bases servers. Dropping of fragmented packets is slowly disappearing with the deployment of DNSSEC. The DNS get slower and slower and eventually people start complaining. Fixing firewalls that are dropping fragmented packets usually just requires a rule change. We can't protect people from doing something wrong/outside spec, nor do I feel we should spend a lot of effort catering to solve their problems for them. Just because my prius can go off-road doesn't mean it's the intended operation nor is covered when I abuse it. Same goes here, vendors and carriers need to tell customers their security technique is unsupported and will break things. It's not the role of the carrier to solve all the problems for the customer who does something weird in this case, unless they're the one creating the problem by using 1000 mtu links w/ IPv6. Any vendor that supports setting the mtu under 1280 on IPv6 should face a reality check sooner vs later. - Jared IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Fragmentation-related security issues
In message 4f060631.1070...@gont.com.ar, Fernando Gont writes: Florian, On 01/05/2012 06:40 AM, Florian Weimer wrote: Do we really know that adding a fragment header to all outgoing packets does not cause them to be rejected? Are you arguing that IPv6 fragmentation does no work at all, or what? I fear that it might work as well as in IPv4, that is, you can only get there with some effort, and for some nodes, it will never work. But that's an entirely different question. If you're thinking about e.g. banning all fragmentation from IPv6, that's certainly completely unrelated to the two I-D's that I've published on the subject... Could this be deployed at large DNS servers in a risk-free fashion, for instance? What's the specific question you're asking, and what is your concern, specifically? If DNS servers started sending either atomic fragments or fragmented responses today (i.e., all generated packets carry an IPv6 extension header), would these servers become unreachable for some clients? (I think we have to assume the answer is yes.) Because some clients ignore atomic fragments, because fragments would be dropped in the path to the client, or what? Note: I'm interested on the topic, but this one has to do more with Mark Andrews' proposal than with mine. -- Mine is about how to improve the state of affairs of IPv6 fragmentation. Mark's is about increasing its use. I'm more about making DNS work reliably. We have forced fragmentation of DNS/UDP/IPv6 datagrams, using IPV6_USE_MIN_MTU, since Jun 2000. Some other vendors havn't and that does result in operational problems as PMTUD is not reliable. Which can be seen when you repeatedly send the same DNS query to the same server but only get the last fragment when there is a tunnel in the reply path. Additionally, even if the PTB message gets through it is usually server to client traffic that gets dropped and servers don't keep a history of the responses they have sent over UDP so it requires a client timeout and requery to get the response resent. If you have a several of servers for a zone it can be several seconds before client retries the query to the first server, even with sub second timeouts, as the client assumes the server is *dead* and moves on to the next server. IPV6_USE_MIN_MTU works for clients that have a MTU path 1280 or greater. IPV6_USE_MIN_MTU does NOT work for clients that have a MTU path 1280, which is a gap in spec. draft-andrews-6man-force-fragmentation is about filling in that gap. IPV6_USE_MIN_MTU was developed to deal with the issue of PMTUD being bad for DNS. draft-ietf-ipngwg-bsd-frag was the early work that eventually became IPV6_USE_MIN_MTU. IPv4 is different in this regard because clients can opt out from fragmented responses by requesting 512 byte responses (even if it's technically a DNS protocol violation). This is just not possible with IPv6---unless the server keeps per-client state, which is a non-starter for large DNS server deployments. Strictly speaking, that's not correct. Requesting 512-byte responses does not necessarily avoid fragmentation. The IPv4 MTU is 68 bytes, not 576. For instance, OpenBSD's imposes a lower limit of 296 (rather than 576 or the like) because such low-MTU technologies exist. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Fragmentation-related security issues
In message 298c387e-66c2-4558-8acf-441a56a7d...@lists.zabbadoz.net, Bjoern A . Zeeb writes: On 3. Jan 2012, at 05:05 , Fernando Gont wrote: On 01/02/2012 07:48 PM, Bjoern A. Zeeb wrote: You'd need to go to the origins most likely and get into touch with them, ask them, work with them to identify things and see if you can find a common denominator... It might really be worth doing so; in case we are hunting misconfiguration s or bugs here and discussing the merits on how to handle other than drop;-) Why should you drop in this case, when it's trivial to process these fragments safely, with no side effects?? Because a fragment header that's not needed a) heats the planet, b-z) does all the things what that means. The more we can force that not to happen the better we are off. Atomic fragments 1280 should not appear in the network. Atomic fragments = 1280 are a expected part of the IPv6 landscape. For TCP they should be rare. For UDP it depends on the protocol running on top of UDP. PMTUD relying on PTB is just not reliable. -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Fragmentation-related security issues
In message 20111220.124458.41706285.sth...@nethelp.no, sth...@nethelp.no writes: IPv6 allows packets to contain a Fragment Header, without the packet being actually fragmented into multiple pieces. Such packets typically result from hosts that have received an ICMPv6 Packet Too Big error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by hosts as fragmented traffic. Does such traffic actually occur in the wild, or would it only be used in attacks? Such traffic absolutely occurs in the wild. I have three reasonably busy name servers where this is logged as an error from the ipfw code, e.g. Dec 16 14:04:04 slem kernel: IPFW2: IPV6 - Invalid Fragment Header Dec 17 00:27:20 slem kernel: IPFW2: IPV6 - Invalid Fragment Header Dec 18 07:53:10 slem kernel: IPFW2: IPV6 - Invalid Fragment Header Dec 18 23:21:37 slem kernel: IPFW2: IPV6 - Invalid Fragment Header Dec 19 03:07:43 slem kernel: IPFW2: IPV6 - Invalid Fragment Header Dec 19 05:09:45 slem kernel: IPFW2: IPV6 - Invalid Fragment Header Dec 19 21:47:46 slem kernel: IPFW2: IPV6 - Invalid Fragment Header Dec 20 08:10:59 slem kernel: IPFW2: IPV6 - Invalid Fragment Header Dec 20 08:59:21 slem kernel: IPFW2: IPV6 - Invalid Fragment Header Dec 20 11:25:59 slem kernel: IPFW2: IPV6 - Invalid Fragment Header This is because these name servers haven't (yet) been upgraded to a FreeBSD version where bug report kern/145733 haven't been fixed. It *is* fixed in newer FreeBSD versions, e.g. 8.2-STABLE. Not yet. http://svnweb.freebsd.org/base/stable/8/sys/netinet/ipfw/ip_fw2.c?view=log Steinar Haug, Nethelp consulting, sth...@nethelp.no IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Fragmentation-related security issues
In message 4ef20beb.8070...@si6networks.com, Fernando Gont writes: Hi, Mark, On 12/21/2011 11:02 AM, Mark Andrews wrote: Such traffic absolutely occurs in the wild. I have three reasonably busy name servers where this is logged as an error from the ipfw code, e.g. Dec 16 14:04:04 slem kernel: IPFW2: IPV6 - Invalid Fragment Header Dec 17 00:27:20 slem kernel: IPFW2: IPV6 - Invalid Fragment Header [] This is because these name servers haven't (yet) been upgraded to a FreeBSD version where bug report kern/145733 haven't been fixed. It *is* fixed in newer FreeBSD versions, e.g. 8.2-STABLE. Not yet. http://svnweb.freebsd.org/base/stable/8/sys/netinet/ipfw/ip_fw2.c?view=log Is the aforementioned traffic the result of an implementation of your proposal for for DNS/UDP? No. I haven't fiddled with any kernel code to do this. I could do it with raw sockets but I havn't done so. The following should work. Bind to a socket so reply traffic is handled then use that socket's port and address to construct a packet with a fragment header to send using the raw socket. My main worry is getting DNS/UDP fragmented at IPv6 minumum MTU as that is not being done today despite the being a API to do it and as a result I'm seeing lookup failures. Forcing the addition of a fragment header is dotting the i's and crossing the t's. The above fix should have been merged by now if the MFC in 2 weeks had been heeded. 8-stable is still FreeBSD's latest stable branch. 9.0 is still at release candidate. Mark If that's the case, what's the interface that you use for forcing the atomic fragments? Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Fragmentation-related security issues
In message 4eeb66d6.7070...@si6networks.com, Fernando Gont writes: Hi, Mark, On 12/15/2011 10:19 PM, Mark Andrews wrote: When thinking about this draft please consider the following: http://tools.ietf.org/html/draft-andrews-6man-force-fragmentation-00 http://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-00 I've just read both of them. The relationship I've found with these two and the two I've authored is that your I-D's will lead to an increase of IPv6 atomic fragments. This means that: * http://tools.ietf.org/id/draft-gont-6man-ipv6-atomic-fragments-00.txt is even more desirable, as it would completely mitigate fragmentation-related attacks against DNS traffic that is not really split into several packets (but still contains a Fragment Header. * Implementation of http://tools.ietf.org/id/draft-gont-6man-predictable-fragment-id-00.txt at the sending node would help mitigate some fragmentation-related attacks against receivers that do not yet implement the atomic packets behaviour described above, or in scenarios in which DNS traffic is really fragmented (i.e., packets are split into multiple pieces). Does this agree with your assessment? Am I missing something? P.S.: I'll be sending feedback about your I-Ds in separate e-mails. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 The real worry is the amount of state that busy authoritative servers will be maintaining. At 13K+ mostly unique clients a second to answer that's a lot of state. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Fragmentation-related security issues
When thinking about this draft please consider the following: http://tools.ietf.org/html/draft-andrews-6man-force-fragmentation-00 http://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-00 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: draft-andrews-dnsext-ipv6-fragmentation
In message dd056a31a84cfc4ab501bd56d1e145c...@exchange.secure64.com, Ste phan Lagerholm writes: Hi Mark, You can get blocked ICMP 'packet too big' even if you have the MTU set to 1280.=20 RFC 2460: In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6=20 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280.=20 In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include=20 a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification=20 value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280=20 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. Which just mean that 6man needs to extend the IPv6 socket API so that the insertion of a fragment header can be signaled. Or IPV6_USE_MIN_MTU=1 needs to imply that a fragment header needs to be added to packets that are not fragmented. Currently IPV6_USE_MIN_MTU doesn't quite fully disable PMTUD. RFC 3542 allows you to turn off adding the adding of Fragment headr by there is no mechanism to force the adding of a Fragment header. /Stephan -Original Message- From: dnsext-boun...@ietf.org [mailto:dnsext-boun...@ietf.org] On Behalf Of Mark Andrews Sent: Sunday, December 04, 2011 6:02 PM To: Paul Hoffman Cc: dns...@ietf.org; Olafur Gudmundsson Subject: Re: [dnsext] draft-levine-dnsextlang-02 =20 On a similar matter I was in the process of submitting the following. I just needed to address internal comments. I also think my EDNS expire option still needs to be addressed though I suspect I'll do that as a individual submission. =20 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Link-local IPv6 addresses in the DNS
In message 4ecc0bab.4040...@gmail.com, Brian E Carpenter writes: On 2011-11-23 05:34, Philip Homburg wrote: In your letter dated Tue, 22 Nov 2011 14:30:03 +1100 you wrote: On a related issue to link locals in URI's, we don't currently have a good method of supporting link locals in the DNS. Sure we can add them as records but they are essentially useless as the scope information is lost. People keep saying use LL for disconnected but it just doesn't work without more support. Other people keep saying use ULA for disconnected. The fact that you can put ULA into (er, local) DNS without any fancy stuff is a distinct advantage. IMHO link-local should be used only for bootstrapping a host and for diagnostic purposes. I guess I could statically configure a printer on fe00::a%1 if I really had no choice. Brian ULA has similar scope issues. It's just that the OS don't knock you over when you do bind(), connect(), sendto() and sendmsg() without scope information. You can avoid using non local ULA with the same filtering mechanisms. For disconnected operation, why not have getaddrinfo fill in the scope? Just set it to the interface over which the DNS reply arrived. I have to admit that this may become a bit tricky if the DNS resolver is lo cal or if interface information is lost in some other way. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Link-local IPv6 addresses in the DNS
On a related issue to link locals in URI's, we don't currently have a good method of supporting link locals in the DNS. Sure we can add them as records but they are essentially useless as the scope information is lost. People keep saying use LL for disconnected but it just doesn't work without more support. Mark DNS host.example.net. S FE80::1 link.example.net. host.example.net. S 2001:DB8::1 . ; . indicates global scope host.example.net. S :::198.51.100.0 . ; . indicates global scope host.example.net. 2001:DB8::1 host.example.net. A 198.51.100.1 RA LINK-NAME link.example.net DHCP LINK-NAME link.example.net getaddrinfo() AI_FILTERED filter scoped addresses which don't match a local scope name. Set in AI_DEFAULT. If you get a response to a S lookup you don't need to do a A/ lookup as it is a superset of A and . host.example.net S :: . indicates a machine that exist but is off net -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [dhcwg] Conflict between RA and DHCP in MIF case
In message 1321238859.2514.73.camel@karl, Karl Auer writes: On Mon, 2011-11-14 at 10:27 +0800, Ole Troan wrote: can you give examples of what information cannot be merged? certainly a default router list can be merged... If one source says that the domain search list is a.com b.com c.com and another source says it is c.com a.com b.com, how can you merge the search lists? Anyone depending apon search lists that they did not set already has a broken configuration. Anyone depending apon search lists in RA's or DHCP messages being honoured by machines already has a broken configuration. Search lists are things that should be set by users for themselves. ISP's SHOULD NOT be setting search lists in DHCP responses to customers. Hotspots's SHOULD NOT be setting search lists in DHCP responses to customers. Enterprises MAY advertise a search lists when configuring their own machines. Homes MAY advertise a search lists when configuring their own machines. Enterprises and homes SHOULD NOT set search lists when responding to DHCP queries on guest networks. Similarly for RA's. Or if one source says that the default route is via IP address 1, and the other source says that the default route is via IP address 2, which IP address are you supposed to use as your default route? Sure, you can set up two default routes - but when a packet turns up for which you have no more specific route, which IP address will you send it to? Something has to choose, using some criterion or other. If they are both true default routers then it doesn't matter which you send to. If they are not then there is nothing a machine can do automatically. Some things cannot be merged - that's what conflict means. Regards, K. --=20 ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-dBD+3PSBkGldJAphgaQ5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk7AgUsACgkQMAcU7Vc29od/4QCbBqCgnAOZiE0+zx3l0VFFGP+2 D0YAnjVCFgBd5WbgE1alnPfi/01lnfQm =zTr6 -END PGP SIGNATURE- --=-dBD+3PSBkGldJAphgaQ5-- --===7419444934332968338== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --===7419444934332968338==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [dhcwg] Conflict between RA and DHCP in MIF case
In message 1321243491.2514.99.camel@karl, Karl Auer writes: On Mon, 2011-11-14 at 14:27 +1100, Mark Andrews wrote: Anyone depending apon search lists that they did not set already has a broken configuration. I didn't say people should do these things, just that there are things that *can be* delivered via RA and that *can be* delivered via DHCP, and that *can conflict*. If things do conflict, then something has to decide, on some criterion or other, which to honour (or to honour neither of course). My post was in answer to a question from someone about about how things could conflict. That's all. Enterprises MAY advertise a search lists when configuring their own machines. Homes MAY advertise a search lists when configuring their own machines. Well - yes. And if their DHCP server says one thing and their RAs are saying another, then there should be a sane default for deciding which to use. That's all this is about. Just let implementations pick one and stick with it until it changes. Difference *will* occur as a matter of operational practice whenever the list is changed so this isn't a error condition unless it continues for a long time. If you update the DHCP server the RA will be out of date. If you update the RA first the DHCP server will be out of date. Regards, K. =20 --=20 ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Question about RFC 3484
In message 4e838725.9010...@gmail.com, Brian E Carpenter writes: On 2011-09-28 21:42, François-Xavier Le Bail wrote: ... So, if the RFC 3484, Section 4 Candidate Source Addresses is involved in the reply to datagrams sent to an anycast address, it might be useful to reassess the restrictions that excluded an anycast address from the candidate set, at least for the replies. You would need to start a thread proposing a specific change to draft-ietf-6man-rfc3484-revise if you want this to be done. I'm not convinced; as Ole said, anycast remains a special case for certain applications, so it will be hard to define a safe general rule. Brian Just for reference, in the last week, there was a compliant in bind-users that we were rejecting replies to queries sent to the all routers IPv6 anycast address because the source address of the reply did not match the destination address of the query. The anycast address can be used as source address relatively safely, even for TCP, if you constrain the packets to be fragmented at network MTU and to also include a fragment header in case they are going through a IPv4/IPv6 translator. With anycast you don't want to trigger PMTU discovery. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: IPv6 prefix notation
In message 3c54fcd8-2835-4171-89a6-c441950f6...@muada.com, Iljitsch van Beijnum writes: On 20 sep 2011, at 9:58, sth...@nethelp.no wrote: For pt2pt SDH links you want /127 to avoid the ping-pong problem, not /126. That's nice (as long as your routers ignore the all zeros anycast address), but the question wa s: how do we write down IPv6 prefixes? Are we ok with simply leaving off the undefined part, or do we insist on proper inclusion of the zeros? If the former, how do we avoid ambiguity for pr efixes such as ::/96? Always specify all 128 bits. Most of the time the minimal representation will end in :: occasionally it won't. For the prefix in question the preferred representation is :::0.0.0.0/96 but :::0:0/96. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: A6 record status
In message 5D36713D8A4E7348A7E10DF7437A4B920122BD2C@SZXEML506-MBS.china.huawei .com, Sheng Jiang writes: In message 4e447c7e.30...@gmail.com, Brian E Carpenter writes: On 2011-08-12 11:47, Mark Andrews wrote: I think it is make work That's why I am only suggesting an IESG decision, not a draft and an RFC. and won't change the amount of confusion. In addition A6 allows compresssion of the domain name in the rdata so it can't be treated as unknown (i.e. a opaque blob) by nameservers. If it's historic, servers shouldn't even contain any A6 records, surely? Making something historic doesn't remove the old software or the old records. Removing knowledge of A6 from recursive server will result in garbage A6 records being delivered to old clients that are A6 aware. A6 aware clients still work as they ask for both and A6 records. Yes, your statement are right. However, the case of A6 is there are few curre nt A6 software or records. As far as I know, there are no commercial A6 suppo rts in the current global DNS system. A6 only existed in some experimental sy stem, like 6net. So, what we are worried here is not these existing A6. By mo ving A6 into historic, we are preventing any NEW A6 implementation or deploym ent. Sheng The root servers are getting 100's of A6 q/s (~20:1 :A6 http://k.root-servers.org/statistics/GLOBAL/daily/). There is still a very large base of A6 using software out there regardless of whether they are getting NODATA responses or not. I don't know what percentage of responses are NODATA and what have actual A6 records. I do think we need to know answers to these sorts of questions. Mark One needs a phase out plan if you want to remove A6 support and it is likely to need to be decades long given how long people run old nameservers for. If one wants to do something about IPv6 addresses in the DNS add support for scoped addresses. Link-local could then be useful. Different topic, and I suspect much more complex. Brian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: A6 record status
I think it is make work and won't change the amount of confusion. In addition A6 allows compresssion of the domain name in the rdata so it can't be treated as unknown (i.e. a opaque blob) by nameservers. If one wants to do something about IPv6 addresses in the DNS add support for scoped addresses. Link-local could then be useful. Mark In message 22f6318e46e26b498abc828879b08d4f1786a...@tk5ex14mbxw652.wingroup.win deploy.ntdev.microsoft.com, Christian Huitema writes: It looked like a great idea at the time, but the time has passed, and historic is clearly appropriate. -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Tina T SOU Sent: Thursday, August 11, 2011 3:13 PM To: Brian E Carpenter; 6man Cc: Tim Chown Subject: RE: A6 record status Brian, I'm with you. I don't use A6 record in any case. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, August 11, 2011 3:06 PM To: 6man Cc: Tim Chown Subject: A6 record status Hi, What do 6man people think about moving RFC 2874 (the A6 record) from Experimen tal to Historic status? It's pretty clear that it doesn't have any real value, and it can still create confusion for newcomers. IMHO this doesn't need a draft; the IESG could just do it. Regards Brian Carpenter IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: A6 record status
In message 4e447c7e.30...@gmail.com, Brian E Carpenter writes: On 2011-08-12 11:47, Mark Andrews wrote: I think it is make work That's why I am only suggesting an IESG decision, not a draft and an RFC. and won't change the amount of confusion. In addition A6 allows compresssion of the domain name in the rdata so it can't be treated as unknown (i.e. a opaque blob) by nameservers. If it's historic, servers shouldn't even contain any A6 records, surely? Making something historic doesn't remove the old software or the old records. Removing knowledge of A6 from recursive server will result in garbage A6 records being delivered to old clients that are A6 aware. A6 aware clients still work as they ask for both and A6 records. One needs a phase out plan if you want to remove A6 support and it is likely to need to be decades long given how long people run old nameservers for. If one wants to do something about IPv6 addresses in the DNS add support for scoped addresses. Link-local could then be useful. Different topic, and I suspect much more complex. Brian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: PMTUD and MTU 1280
In message 071801cc4afb$b3ead4a0$1bc07de0$@com, Dan Wing writes: -Original Message- From: R=E9mi Despr=E9s [mailto:despres.r...@laposte.net] Sent: Monday, July 25, 2011 1:43 PM To: Dan Wing Cc: 'james woodyatt'; 'RJ Atkinson'; ipv6@ietf.org Subject: Re: PMTUD and MTU 1280 = Dan, = 1. The point I wanted to check is just, slightly reformulated): May a simple IPv6 host have no support of packet-reassembly, and simply accept packets up to 1280 octets. The earlier part of this thread was talking about sending; you're now bringing up receiving. IMO, if the packet came from IPv4, and that IPv4 network had a small MTU (e.g., 576) causing fragmentation, then such an IPv6 receiver will be unable to receive the packet. In my understanding, the answer should be yes. - This doesn't depend on whether sources know or not whether their destinations are IPv6 or IPv4 only. - If the destination happens to be IPv6, current RFC's don't permit intermediate nodes to refuse 1280 packets as being too big. = 2. How sources can be sure to have e2e transparency in IPv6 is a different question, but IMHO an important one. = For instance, if a destination address is obtained from the DNS in a , with no A for the same URL and without any well-known prefix indicating that there is an embedded-IPv4-address, I hope the source can be guaranteed that e2e transparency won't be broken? I don't think so. DNS64 comes to mind. I won't have time personally to contribute much on this, but the subject would usefully be clarified, IMHO. The RFCs are pretty clear, IMO. Implementers don't want to read them all the way. And there is missing functionality in the API's. IPV6_USE_MIN_MTU doesn't force a fragment header to be added to packets less than 1280 octets for example and I'm not aware of any other API hooks which will do this. As a result a node still has to do some parts of path mtu discovery even if it doesn't want to and it is undesirable for it to do so. RFC 3542 This specification defines a mechanism to avoid path MTU discovery by sending at the minimum IPv6 MTU [RFC-2460]. If the packet is larger than the minimum MTU and this feature has been enabled the IP layer will fragment to the minimum MTU. To control the policy about path MTU discovery, applications can use the IPV6_USE_MIN_MTU socket option. A application should be able to send a IPv6/UDP packet, without resorting to using raw sockets, and not have a PTB be generated as a result. Mark -d Regards, RD = = Le 25 juil. 2011 =E0 15:36, Dan Wing a =E9crit : = ... Its behavior violates the last paragraph of Section 5 of RFC2460. Violation _only in case_ of an IPv6 packet that is sent to an IPv4 destination. But how does one determine an IPv6 packet is, or isn't, going to an IPv4 destination? I don't think it's possible to determine if there is an IPv6/IPv4 translator on the path. -d If the destination is IPv6, a PMTU below 1280 remains therefore a network failure. This authorizes a simple IPv6 host to refuse packets beyond 1280 octets and to have no support of packet-reassembly. Right? Regards, RD -d -- james woodyatt j...@apple.com member of technical staff, core os networking -- -- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- -- --- - IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --- - IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: PMTUD and MTU 1280
In message m1qjmmi-0001...@stereo.hq.phicoh.net, Philip Homburg writes: In your letter dated Wed, 20 Jul 2011 17:35:31 -0400 you wrote: I am not sure the specs insist that an IPv6 implementation must treat an ICMPv6 Packet-Too-Big for less than 1280 bytes as unrecoverable. (I haven't re-read the IPv6 specs recently.) Some services, like big DNS server cannot afford to do PMTU. It requires them to store the original DNS reply just in case an ICMP comes back. This was originally noted in draft-ietf-ipngwg-bsd-frag-00 (January 1998) and became IPV6_USE_MIN_MTU (RFC 3542, May 2003). Now if we can just get it into POSIX And, yes, nameservers do set this option. FreeBSD's implementation however is partially broken. See: http://www.freebsd.org/cgi/query-pr.cgi?pr=158307. Without that, the host will see that its first request fails and has to retry . Over time, this will happen again and again because big servers cannot maintain all PMTU state forever. It takes multiple requests usually and yes the state does get lost within minutes on busy nameservers. What should have been specified is that hosts need to fragment packets into roughly equal sizes fragments. This reduces the probabilty of having to deal with multiple PTB packets. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
For many years I just filtered out rogue RA's on my laptop at IETF. I looked at which routers were advertising which prefixes and configured a allow list in the firewall for those that looked correct and denied the rest. Then I removed the bogus addresses, generated as the result of those RA's, from the interface. I also remove the default route when it pointed to a bogus router and performed a router solicitation. Making that into a GUI so the user can point and click should be relatively easy. Add to that next hop selection where you only send to a router that is advertising a prefix covering the source address you are using and trying from multiple source address, you can mostly eliminate the impact of accidental rogue RA's without needing to filter. If you want to eliminate malicious RA's then you need the network operator to help by using CGA's or similar so you can identify spoofed from non-spoofed RA's. The node can learn which router is using CGA's and automatically filter spoofed ones. By keeping a little more state it can also automatically cleanup the side effects from those spoofed RA's. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [BULK] Re: draft-yhb-6man-slaac-improvement-00
In message b0147c3dd45e42478038fc347ccb65fe02a7643...@xch-mw-08v.mw.nos.boeing .com, Manfredi, Albert E writes: I guess I'm missing what the solution is. As 3177-bis says, the IETF has no control over how service providers hand out IPv6 address space. From what I've been reading in the past few years, it lo oks like at least some providers are planning to give /64s to customers. Every ISP I've seen make that claim has also thought they need to fit into a /32. Once they were informed that that was not the case they changed their plans. Additionally the *nog lists see /56 as being standard these days (changed from about 6 months ago). There are still arguments about /48 but the /56 vs /64 has gone to /56. The way I see it, unless we permit SLAAC to use more than 64-bit prefixes, ei ther of two things will happen. 1. SLAAC will not work inside home networks, except for the simplest one-comp uter case, or 2. Someone will have the brilliant idea to invent an IPv6 NAT. As Mark points out, this may encourage providers to hand out /127s. So, rock and hard place. What's the answer, if no one can force providers to hand out AT LEAST /56s? NAT? Competition will. CPE device manufactures will. Prefix delegation is being delivered today as part of the basic IPv6 functionality set in CPE devices. Remember HE hands out /48's for free to anyone in the world today. 6to4 delivers /48. Current 6rd (RFC 5969) supports just about an sized prefix. I don't think this is something that needs to be solved as it is a non problem. Bert -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Ping6 utility issue:-
In message l2tfc485cbb1005030343qb2df7634u1a486e38531f8...@mail.gmail.com, niviya vijayan writes: Hi All, I am using linux os version 2.6.10 and i have an mtu configured 1500 .When i do a ping6 request with size 1800 and DF bit set as yes, i could see a fragmentation happening eventhough DF bit is set. As per my understanding , Ping6 request has to be dropped.Correct me if am wrong.Did anyone face this issue anytime before? Looking forward to hear from you... Regards, Niviya Fragmentation and DF are not mutually exclusive. DF says don't fragment when forwarding. When you are originating the packet you are not forwarding. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: FYI: DNSOPS presentation
In message 4bb75ab0.40...@redpill-linpro.com, Tore Anderson writes: Hi, * Olivier MJ Crepin-Leblond Completely in agreement, although I'd like to add ...and whether such solutions are required. Currently, the number of end users who can connect to a single-stack IPv4 web site is greater than the number of end users who can connect to a dual-stack web site. This situation must change, or you won't be seeing much IPv6 content appearing on the internet anytime soon. I feel uneasy messing around with the DNS by introducing ugly hacks to resolve a problem with 0.078% of people, thus affecting 99.922% of people who had no problem and who might then end up having a problem due to the hack. The obvious solution to this is currently to _not_ deploy IPv6 on existing content. For now, that will keep ~100% of users happy, and doesn't require any DNS hacks/whitelists to be maintained. But I still would like to deploy IPv6 somehow. Suggestions on how exactly I can go about doing that, without messing around with DNS or breaking connectivity for users who up until now have had no problems, would be greatly appreciated. The first thing is to publish a complete description of the testing methodology and envionment. So far I havn't see it. Most of the transition technology involves encapsulation so was the mtu set to prevent pmtud being triggered due to encapsulation in IPv4? route add net 2002::/16 mtu 1480 or route add net 2002::/16 mtu 1280 What are the figures when you do this? Does either of these change the percentages? Similarly for route change net ::/0 mtu 1480 and route change net ::/0 mtu 1280 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: FYI: DNSOPS presentation
In message 4bb75ab0.40...@redpill-linpro.com, Tore Anderson writes: Hi, * Olivier MJ Crepin-Leblond Completely in agreement, although I'd like to add ...and whether such solutions are required. Currently, the number of end users who can connect to a single-stack IPv4 web site is greater than the number of end users who can connect to a dual-stack web site. This situation must change, or you won't be seeing much IPv6 content appearing on the internet anytime soon. I feel uneasy messing around with the DNS by introducing ugly hacks to resolve a problem with 0.078% of people, thus affecting 99.922% of people who had no problem and who might then end up having a problem due to the hack. The obvious solution to this is currently to _not_ deploy IPv6 on existing content. For now, that will keep ~100% of users happy, and doesn't require any DNS hacks/whitelists to be maintained. But I still would like to deploy IPv6 somehow. Suggestions on how exactly I can go about doing that, without messing around with DNS or breaking connectivity for users who up until now have had no problems, would be greatly appreciated. You turn IPv6 on a service at a time. Turn it on for delay tolerent services. e.g. SMTP. Turn it of for services which try different servers quickly. e.g. DNS. Turn it on for the client side. There may be few place to connect to now but the ratio of good to bad will get better as more people turn up IPv6 as a production service on the client side. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: FYI: DNSOPS presentation
In message 4bb783a3.3020...@redpill-linpro.com, Tore Anderson writes: Hi Mark, * Mark Andrews You turn IPv6 on a service at a time. Turn it on for delay tolerent services. e.g. SMTP. Turn it of for services which try different servers quickly. e.g. DNS. Turn it on for the client side. Sure thing, I've already done some of those, but it won't really change much. There's no real reason for a end-user to contact my SMTP or DNS servers directly, as he will normally relay e-mail/DNS queries via his own ISPs servers anyway. And the fact that all the workstations at my office have native IPv6 connectivity doesn't have any effect on all the broken end users in other networks. Except it does, people saying we have IPv6 connectivity and it didn't break things will cause more people to turn on IPv6 as a production service which will disable the automatic transition mechanisms. The problematic service is without question the web sites. There may be few place to connect to now but the ratio of good to bad will get better as more people turn up IPv6 as a production service on the client side. Absolutely. I'm sure that at some point in the future there'll be more end users able to connect to a dualstacked web site than there is end users able to connect to a IPv4-only site. At that point you'll see lots of IPv6 content showing up. No problem. However, when will that point in time be? Well we've had dual stack servers for years now so for us that point has long ago passed. We log bug reports when a service is not available over IPv6 as well as IPv4. The way it's going right now it seems to me that it will be well after IPv4 pool is exhausted, when the IPv4 internet is starting really to crumble under CGNs and other life-extending band-aids. I'm more impatient than that though, and don't want to just sit around and wait until then. It appears other content providers like Yahoo and Google don't either. But short of resorting to DNS tricks, or attempting to persuade all the end users' ISPs and/or software vendors to fix their problems, I really don't see what else can be done. By the way I actively pursue the option of asking problematic networks and software vendors to fix their problems. It's a very slow process, though. Even when software patches are released, it takes lots of time before a sufficient amount of end-users have applied them. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: next steps with 6man-text-addr-representation
In message 4b6c14d2.60...@piuha.net, Jari Arkko writes: This draft was on the IESG review yesterday, and did not get approved due to a number of Discusses from the other ADs. There's a number of small details that we can talk about separately, but I wanted to talk to the working group about the high level issues. Generally speaking the reviewers were surprised about the lack of preciseness in the definition of the canonical form. This had to do with the IPv4-embedded addresses, the specification style and lack of MUST keywords, and so on. I think everyone believed the draft as currently written will already improve things, but many reviewers felt that it could have been much stricter. The reviewers were also wondering about the role of the draft, will it affect everything or just other specifications that decide to adopt the new format. I explained the situation with the IPv4-embedded addresses -- this is a design tradeoff where we can either nail down everything now and not have a nice textual representation in some cases, or we can leave some flexibility. We've already had this discussion in the working group, and I believe we keep the current approach in the draft. However, we need to add the rationale to the draft so that future readers are not asking the same questions as our reviewers did now. Then we talked about the strictness. I explained that this is largely a specification style issue, and in the real world there will always be old code that doesn't produce the canonical form, and that we hope that this RFC will convince all new code to do the right thing. However, we came up with the following proposal to make the specification stricter: - Use RFC 2119 language and MUST. Implementations conforming to this specification MUST ... - Provide a reference to the currently defined WKPs - In the section that talks about ports, please make sure that for URIs everyone MUST follow RFC 3986, and for the rest, the default can be again RFC 3986. The current language leaves everything open, even for URIs. - There's a part about reducing longest sequence of 0s -- it would be great if we could point to some publicly available code that already does this, as an informational reference to implementors ISC's inet_ntop() was released in 1996 as part of BIND 8. It's also in BIND 9. - We will keep the specification on the Standards Track, i.e., publish it as a Proposed Standard - This specification Updates RFC 4291 Would these changes be acceptable to the working group? Jari IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Are IPv6 auto-configured addresses transient?
One thing we do need to do is to push more address state into the DNS. Today we just have records. We want to able to map from address to names and names to addresses as long as the mappings exist. We also want to stop using deprecated addresses as soon as possible. doesn't have enough information to meet both needs. We can remove deprecated address but then we loose the ability to map. We can keep the deprecated addresses but then we don't preference the non deprecated address when establishing new sessions. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Multiple Prefixes in RA
In message 5988ed3c0910010500i69d21db9p1a4c8c8b8539d...@mail.gmail.com, Vijay rajan ranganathan writes: Hi, Perhaps a naive question, but can somebody mention some practical use cases for advertising multiple prefixes in a Router Advertisement? ULA + Gobal Renumbering Thanks Regards Vijay IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [BEHAVE] Perils of structured host identifiers (was: Modified EUI-64 format)
In message 6504f50e-c15b-4233-bd5d-f917f35bb...@muada.com, Iljitsch van Beijn um writes: On 8 jul 2009, at 15:12, R=E9mi Despr=E9s wrote: The u/l bit is reserved for global use as Brian Carpenter also noted. Well, it gets complex. Discussing the point offline in Stockholm might be better than by mail. Would that be useful? The whole point of NAT64 is to work with unmodified clients. So the clients don't care. The DNS64 has to stuff the IPv4 bits somewhere in the IPv6 bits. Although it's simpler to do that at a 32 bit boundary (and a 16 bit boundary has checksumming advantages), as far as I know all of this happens in software and can be handled fast enough even if the rules get more complex to have decent performance on a normal DNS server like machine. On the NAT64 translator side I'm a bit worried that vendors may want to use hardware acceleration which won't be very flexible with regard to the place in the IPv6 address where the IPv4 address appears. For that reason, I would like to mandate that the IPv4 bits ALWAYS appear in the bottom 32 bits of the IPv6 address. But we can leave this upto the vendors, if they can afford to be flexible they'll be flexible and customers that need flexibility will buy those products, if flexibility is too expensive they won't put it in and only people who don't care buy the products. Especially if we assume that the vendors of DNS64s and NAT64s are going to be the same there are no problems with updating the prefix format so there is no need to specify one other than a reasonable default, which would obviously be whatever/96 + IPv4 because that's what existing NAT-PTs do. Why make that assumption? Leave the DNS to those that know the DNS. I don't see a DNSSEC being added a 50USD CPE device anytime soon. I do see NAT64 being added and a basic DNS64 being added. It took me 1/2 a day to add IPv6 synthesis from IPv4 to a DNS server. It take months to add working DNSSEC to a DNS server. Stop trying to be over clever here. KISS. Mark ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Review requested: draft-kawamura-ipv6-text-representation-02
In message 4a0d0510.3010...@mesh.ad.jp, Seiichi Kawamura writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 management tools/etc. Sometimes that's unavoidable, but the point of a recommendation is to avoid problems whenever you can. You do have a point there. WindowsXP(netstat) [2001:db8::1]:80 FreeBSD7.1(netstat) 2001:db8::1.80 FreeBSD7.1(ipfw) [2001:db8::1]:80 Linux CentOS4(netstat) 2001:db8::1:80 linux+apache [2001:db8::1]:80 square brackets may be the more popular but this is debatable. For example Unbound's log gives 2001:db8::1 port 53 and that's not so bad. named 2001:500:7::79#53 and 198.133.199.4#53 tcpdump 2001:470:1f00:820:214:22ff:fed9:fbdc.61867 and 207.46.216.54.80 IPv4 added for comparision. Are there others who think this should be covered in the draft? Any ideas? Regards, Seiichi Dave Thaler wrote: -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Seiichi Kawamura Sent: Thursday, May 14, 2009 6:05 PM To: Dave Thaler Cc: 6man; Brian E Carpenter Subject: Re: Review requested: draft-kawamura-ipv6-text-representation- 02 Yep, the problem with the notation quoted in Brian Haley's email is that 2001:4860:b003::68:80 when viewed without knowing the context is ambiguous as to whether it's an IPv6 address, or an IPv6 address + port 80. Yes, this is the most ambiguous of the situations. BTY, FreeBSD gives. I'm pretty used to this. 133.205.1.1.80 2001:260::1.80 IMHO, the way port numbers are presented is not really a big problem if we don't get something as Dave noted. Would it make sense to include somewhere a sentence that says something like It is recommended that one avoids an ambiguous separtor when displaying addresses and port numbers together? Personally, I'd rather see a recommendation that everything use the same separator whenever possible, rather than recommending that everything use some separator that isn't ambiguous. Otherwise, you run into lots of conversion problems when you try to pass strings between different protocols/apps/ management tools/etc. Sometimes that's unavoidable, but the point of a recommendation is to avoid problems whenever you can. -Dave Seiichi Kawamura - IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 - - -- ## NEC BIGLOBE Ltd. Platform Systems Division Seiichi Kawamura kawamu...@mesh.ad.jp TEL : 03-3798-6085 (FAX: 03-3798-6029) Mobile: 090-1547-4791 ## -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) iD8DBQFKDQUQcrhTYfxyMkIRAvquAJ9snCxByDQUqSTBgLA3HMwiVHw+wACfUZwi n9VCykOspbJsRJPcLucB8pY= =dVSw -END PGP SIGNATURE- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Review requested: draft-kawamura-ipv6-text-representation-02
In message 4a0c90bf.4010...@gmail.com, Brian E Carpenter writes: On 2009-05-15 05:40, Dave Thaler wrote: I read and I agree with the document except for Appendix A. For one, I disagree that v4 mapped addresses are not recommended. They're commonly used for sockets that support both IPv4 and IPv6. Secondly, ISATAP (RFC5214) and IPv4-translated (RFC2765) addresses are not mentioned and they also use the decimal form in the low 32 bits. I would recommend moving up into the body of the doc a discussion of the ambiguity between, for example :::127.0.0.1 :::7f00:1 Yes. There is a technical ambiguity in RFC4379 caused by this. http://www.rfc-editor.org/errata_search.php?eid=1418 (You can argue that the suggested fix is sloppy too, but at least it isn't ambiguous. If we agree here, I can ask the RFC Editor to update the fix.) And explicitly recommend that forms for which dotted decimal is legal should always be displayed with dotted decimal rather than hex. On 2009-05-15 06:58, Dave Thaler wrote: I'll note that the netstat output below is arguably non-standard since it i ncludes port numbers without encosing the address in []. (The arguable part is whether [] is limited to URLs or applies in general) As far as I know it's defined for URIs in RFC3986 and SIP in RFC3261. Windows would display them as [::]:22 etc. Perhaps this draft should be extended to cover text representation of IPv6 addresses + ports, and discuss this issue? The combination of RFC3261 and draft-ietf-sip-ipv6-abnf-fix is supposed to combine the RFC4291 syntax, the RFC3986 square brackets, and :port, such that [::]:22 would indeed be the result, whereas 127.0.0.1:22 would be the result for IPv4. http://[2001:4860:b003::68]:80 works fine with Firefox and IE. I agree that it would be reasonable to recommend this as best practice. Brian [] is a kludge to get around protocols that had : already embedded as a token seperator. ISC looked at this over 10 years ago when we were developing BIND 9 and went with address#port where address can have a scope identifier %scope. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Review requested: draft-kawamura-ipv6-text-representation-02
In message 4a0cbd15.5080...@gmail.com, Brian E Carpenter writes: Mark, On 2009-05-15 12:11, Mark Andrews wrote: ... [] is a kludge to get around protocols that had : already embedded as a token seperator. ISC looked at this over 10 years ago when we were developing BIND 9 and went with address#port where address can have a scope identifier %scope. If we could rewrite history a) TimBL would not have relied on semantics to distinguish names from addresses in URIs b) IPNGWG would have chosen a different separator than : but I think we can't rewrite history. We had this discussion prior to RFC3732 iirc. Brian We are constrained to use : for some protocols. Using [] when so contrained make sense. Forcing [] when not so contrained does not make sense. It's the tail wagging the dog. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: End System PMTUD behavior question
reduce the ICMP message size to avoid IP = fragmentation./FONT/DIV=0A= DIV dir=3DltrFONT face=3DCourier New size=3D2/FONTnbsp;/DIV=0A= DIV dir=3DltrFONT face=3DCourier New size=3D2Peter = Hunt/FONT/DIV=0A= DIV dir=3DltrFONT face=3DCourier New size=3D2Software = Engineer/FONT/DIV=0A= DIV dir=3DltrFONT face=3DCourier New size=3D2Nokia = Samp;S./FONT/DIV=0A= DIV dir=3DltrFONT size=3D2/FONTnbsp;/DIV/DIV/BODY/HTML --_=_NextPart_001_01C97CEC.C9F8E0DD-- --===0174434914== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --===0174434914==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: End System PMTUD behavior question
In message 3c6f21684e7c954193e6c7c4573b762701d3dd7...@imcmbx1.mitre.org, Dun
n, Jeffrey H. writes:
Mark,
Could you elaborate on what you mean by DNS servers just tell the kernel t=
o fragment at network mtu for UDP/IPv6 and ensure that DF is off for UDP/IP=
v4. What is the network MTU? Also, to which implementations of DNS serv=
er are you referring?
Cut-and-pasted from BIND's bsd socket implementation.
Mark
#ifdef IPV6_USE_MIN_MTU/* RFC 3542, not too common yet*/
/* use minimum MTU */
if (sock-pf == AF_INET6) {
(void)setsockopt(sock-fd, IPPROTO_IPV6,
IPV6_USE_MIN_MTU,
(void *)on, sizeof(on));
}
#endif
#if defined(IP_MTU_DISCOVER) defined(IP_PMTUDISC_DONT)
/*
* Turn off Path MTU discovery on IPv4/UDP sockets.
*/
if (sock-pf == AF_INET) {
int action = IP_PMTUDISC_DONT;
(void)setsockopt(sock-fd, IPPROTO_IP, IP_MTU_DISCOVER,
action, sizeof(action));
}
#endif
#if defined(IP_DONTFRAG)
/*
* Turn off Path MTU discovery on IPv4/UDP sockets.
*/
if (sock-pf == AF_INET) {
int off = 0;
(void)setsockopt(sock-fd, IPPROTO_IP, IP_DONTFRAG,
off, sizeof(off));
}
#endif
Best Regards,=20
=A0=20
Jeffrey Dunn=20
Info Systems Eng., Lead=20
MITRE Corporation.
(301) 448-6965 (mobile)
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: in6_pktinfo etc still missing in POSIX specs
In message [EMAIL PROTECTED], Thomas Narten writes: I'm not involved in this in detail, so I may be off base, but my understanding is that the advanced API has not been picked up by Open Group because its members didn't support doing so -- they just didn't see a need to. My own take is that standardization of the advanced API just isn't compelling. When I did a survey in the past of what various vendors had done with the advanced API, I found that none implemented it completely. Rather, most implemented bits and pieces of it depending on what applications needed the funcitonality (or just implemented private versions for the applications that needed the functionality). And since the functionality in the adnvanced API (by definition) isn't needed accept by fairly exotic usages, it's hard to make the arguement that it needs to be implemented for basic interoperability. Thomas IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 If you want to make UDP replies work without using a descriptor per address you listen on you need part's of the advanced API. Named uses the advanced API to get reply UDP traffic sourced from the correct address. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: in6_pktinfo etc still missing in POSIX specs
In message [EMAIL PROTECTED], Thomas Narten writes: I'm not involved in this in detail, so I may be off base, but my understanding is that the advanced API has not been picked up by Open Group because its members didn't support doing so -- they just didn't see a need to. One shouldn't have to have OS specific knowledge to write IPv6 code. Failure of POSIX to ratify the advanced API is causing that to happen. This is not conjecture. It is fact. We need more standisation not less. The following was just committed to the BIND sources. 2463. [port] linux: POSIX doesn't include the IPv6 Advanced Socket API and glibc hides parts of the IPv6 Advanced Socket API as a result. This is stupid as it breaks how the two halves (Basic and Advanced) of the IPv6 Socket API were designed to be used but we have to live with it. Define _GNU_SOURCE to pull in the IPv6 Advanced Socket API. [RT #18388] My own take is that standardization of the advanced API just isn't compelling. When I did a survey in the past of what various vendors had done with the advanced API, I found that none implemented it completely. Rather, most implemented bits and pieces of it depending on what applications needed the funcitonality (or just implemented private versions for the applications that needed the functionality). And since the functionality in the adnvanced API (by definition) isn't needed accept by fairly exotic usages, it's hard to make the arguement that it needs to be implemented for basic interoperability. Thomas -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Why would anyone want to use a 64 bit interface identifier?
__ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: RFC 4193
Hi, Is there any implementation available for RFC 4193 (Unique Local IPv6 Unicast Address) on a host machine? Yes. ALL EXISTING IPV6 IMPLEMENTATIONS SUPPORT THIS. Find a ethernet card. Push the address through a cryptographic hash. Select a group of octets. Mark % ifconfig bge0 bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING inet6 fe80::214:22ff:fed9:fbdc%bge0 prefixlen 64 scopeid 0x1 inet 192.168.191.236 netmask 0xff00 broadcast 192.168.191.255 inet6 fd92:7065:b8e:0:214:22ff:fed9:fbdc prefixlen 64 autoconf inet6 2001:470:1f00:820:214:22ff:fed9:fbdc prefixlen 64 autoconf ether 00:14:22:d9:fb:dc media: Ethernet autoselect (10baseT/UTP half-duplex) status: active % echo 00:14:22:d9:fb:dc | md5 6fb5ee6273a57a2d597e62bbc84e1a13 % Since the Global ID in these address are to be randomly generated, there is no way to manual assign a local ipv6 address to an interface? Regards, Prabhu H -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: RFC 4193
Thanks for the reply Mark! The local ipv6 address output line contains autoconf flag, so I believe this has been configured after reception of RA packet with prefix fd92:7065:b8e:0 inet6 fd92:7065:b8e:0:214:22ff:fed9:fbdc prefixlen 64 autoconf If this is the case, then I assume all the nodes in the site will have the same prefix (includes global id). So from the host point of view, this local ipv6 address will behave like yet another global address and doesn't need any implementation for generating random global id. Yep. It's a site prefix. Your border routers should, by default, be configured to block traffic to and from ULA in addition to the usual spoofed traffic suppression. e.g. 01600 unreach admin ipv6 from any to fc00::/7 via gif0 01700 unreach admin ipv6 from fc00::/7 to any via gif0 Note: this sends back ICMPv6 messages. You really do want your border routers to tell the applications/kernel that they have choosen the wrong IPv6 source address. Mark Regards, Prabhu H On Jan 8, 2008 5:29 PM, Mark Andrews [EMAIL PROTECTED] wrote: Hi, Is there any implementation available for RFC 4193 (Unique Local IPv6 Unicast Address) on a host machine? Yes. ALL EXISTING IPV6 IMPLEMENTATIONS SUPPORT THIS. Find a ethernet card. Push the address through a cryptographic hash. Select a group of octets. Mark % ifconfig bge0 bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING inet6 fe80::214:22ff:fed9:fbdc%bge0 prefixlen 64 scopeid 0x1 inet 192.168.191.236 netmask 0xff00 broadcast 192.168.191.255 inet6 fd92:7065:b8e:0:214:22ff:fed9:fbdc prefixlen 64 autoconf inet6 2001:470:1f00:820:214:22ff:fed9:fbdc prefixlen 64 autoconf ether 00:14:22:d9:fb:dc media: Ethernet autoselect (10baseT/UTP half-duplex) status: active % echo 00:14:22:d9:fb:dc | md5 6fb5ee6273a57a2d597e62bbc84e1a13 % Since the Global ID in these address are to be randomly generated, there is no way to manual assign a local ipv6 address to an interface? Regards, Prabhu H -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] --=_Part_27878_32489016.1199797894384 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for the reply Mark!brbrThe quot;local ipv6 addressquot; output l ine contains quot;autoconfquot; flag, so I believe this has been configured after reception of RA packet with prefix quot;fd92:7065:b8e:0quot; brbrinet6 fd92:7065:b8e:0:214:22ff:fed9:fbdc prefixlen 64 autoconfbrbr If this is the case, then I assume all the nodes in the site will have the s ame prefix (includes global id).nbsp; So from the host point of view, this l ocal ipv6 address will behave like yet another global address and doesn#39;t need any implementation for generating random global id. brbrRegards,brPrabhu Hbrbrbrdiv class=gmail_quoteOn Jan 8, 20 08 5:29 PM, Mark Andrews lt;a href=mailto:[EMAIL PROTECTED]Mark_Andre [EMAIL PROTECTED]/agt; wrote:brblockquote class=gmail_quote style=border-le ft: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1e x; div class=Ih2E3dbrgt; Hi,brgt;brgt; Is there any implementation available for RFC 4193 (Unique Local IPv6brgt; Unicast Address) on a quot ;host machinequot;?brbr/div nbsp; nbsp; nbsp; nbsp;Yes. nbsp;ALL EXISTING IPV6 IMPLEMENTATIONS SUPPORT THIS. brbr nbsp; nbsp; nbsp; nbsp;Find a ethernet card. nbsp;Push the addr ess through a cryptographicbr nbsp; nbsp; nbsp; nbsp;hash. nbsp;Select a group of octets.brbr nbsp; nbsp; nbsp; nbsp;Markbrbr% ifconfig bge0brbge0: flags=8843lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICASTgt; mtu 1 500 br nbsp; nbsp; nbsp; nbsp;options=1blt;RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWT AGGINGgt;br nbsp; nbsp; nbsp; nbsp;inet6 fe80::214:22ff:fed9:fbdc%bge0 prefixlen 64 scopeid 0x1br nbsp; nbsp; nbsp; nbsp;inet a href=http:/ /192.168.191.236 target=_blank192.168.191.236/a netmask 0xff00 broadcast a href=http://192.168.191.255; target=_blank 192.168.191.255/abr nbsp; nbsp; nbsp; nbsp;inet6 fd92:7065:b8e:0:21 4:22ff:fed9:fbdc prefixlen 64 autoconfbr nbsp; nbsp; nbsp; nbsp;inet6 2 001:470:1f00:820:214:22ff:fed9:fbdc prefixlen 64 autoconf br nbsp; nbsp; nbsp; nbsp;ether 00:14:22:d9:fb:dcbr nbsp; nbsp; nb sp; nbsp;media: Ethernet autoselect (10baseT/UTP lt;half-duplexgt;)br n bsp; nbsp; nbsp; nbsp;status: activebr% echo 00:14:22:d9:fb:dc | md5br 6fb5ee6273a57a2d597e62bbc84e1a13br%brdivdiv /divdiv class=Wj3C7cbrgt; Since the quot;Global IDquot; in these a ddress are to be randomly generated, therebrgt; is no way to manual assign a local ipv6 address
Re: [DNSOP] Re: getaddrinfo() and searching
--On Friday, 28 September, 2007 09:48 +1000 Mark Andrews [EMAIL PROTECTED] wrote: ... It's not. Even without IPv6, having search domains means you can get unexpected results. If that's not acceptable, don't complain, but put a period behind your FQDNs. Please state were in RFC 952 a final period is legal in a hostname. Remember applications take HOSTNAMES not DOMAIN NAMES. There are HOSTNAMES that you cannot store in the DNS. There are DOMAIN NAMES that are not legal HOSTNAMES. Mark, your recollection and understanding of history and vocabulary may be different from mine (and probably is), but I think you are getting confused by some informal terminology and risking confusing others even further. RFC 952 in fact prohibits trailing periods in domain names used as host names, but 952 is a very early document, superceded by all sorts of things both formally and informally. I note, for example, that it has been a rather long time since every boundary router on the network (a gateway) had a name ending in -GW or -GATEWAY. Please don't read sentences of 952 out of context and consider them binding. You will not find the hostname versus domain distinction made in RFC 1034. Actually will find the distinction made. Please go re-read RFC 1034 and RFC 1035. Mark 3.5. Preferred name syntax The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes. However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs. For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names. Note: NS specifies a HOST. 3.3.11. NS RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / NSDNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NSDNAME A domain-name which specifies a host which should be authoritative for the specified class and domain. Note: CNAME is a general DOMAIN. 3.3.1. CNAME RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: CNAME A domain-name which specifies the canonical or primary name for the owner. The owner name is an alias. 1034 and its conceptual predecessors discusses the domain name system as a replacement for the hostname one and even notes (correctly) that different applications have different syntax rules for names for hosts. To make the ambiguity worse, when the term host or hostname is used in applications in conjunction with the DNS, that term often refers to the leaf-note label and not to the FQDN. See, for example, section 3.7 of RFC 821, which describes Fred.Cambridge.UK as a possible host-and-domain identifier. However, the familiar mailbox is defined as mailbox ::= local-part @ domain Note that it is not local-part @ hostname or local-part @ host-and-domain RFC 1034 also seems to believe that all fully-qualified (aka absolute) domains names, including those used to refer to hosts, end in a period, even if that period is typographically omitted for convenience. Of course, it also contains a masterwork of apparently-circular definition: A domain is identified by a domain name, and consists of that part of the domain name space that is at or below the domain name which specifies the domain. While 1034 suggests that the trailing period is always permitted, even if it is implied, Section 2.3.1 of 1035 gives a syntax that doesn't permit them. But it does so without trying to distinguish between a host and a domain. In particular, it says that [all of] The labels must follow the rules for ARPANET host names, which is ultimately a reference to 952 although 1035 repeats the rule. That rule is applied to all labels, not just the leaf one or ones identifying hosts. As an indirect illustration of this, note that 1035 Section 3.5 describes IN-ADDR.ARPA as supporting host address to host name mapping. That mapping is to an FQDN, not a label or hostname as you use the term above. It does for almost all possible hostnames. Maximum length hostnames can't fit into the DNS
Re: [DNSOP] Re: getaddrinfo() and searching
On 27-sep-2007, at 3:33, Mark Andrews wrote: So your issue that the results are inconsistent is certainly real. I'd say that the best way to avoid this is not having a search domain at all, or at the very least not several. Which is a totally unreasonable suggestion. It's not. Even without IPv6, having search domains means you can get unexpected results. If that's not acceptable, don't complain, but put a period behind your FQDNs. Please state were in RFC 952 a final period is legal in a hostname. Remember applications take HOSTNAMES not DOMAIN NAMES. There are HOSTNAMES that you cannot store in the DNS. There are DOMAIN NAMES that are not legal HOSTNAMES. The problem here is not the search but different stoping critera depending apon the address families supported by the host or requested by the application. We wrote a API that failed to account for the usual use senario. In fact the guidance in there is the direct opposite of what should be done with the usual use senario. I thought the solution would be hard or would be suboptimal in the common case, but I think that doesn't have to be so. In my example, MacOS would go through the search domains and keep going until it found records for IPv6 or IPv4+IPv6 applications (and presumably look for A records if there were no records and IPv4 was present/requested also). So basically, both the answers = 0, noerror and nxdomain responses trigger trying the next search domain. If we change this to answers = 0, noerror means try the same FQDN again for an A record, and nxdomain means move on to the next search domain, the results for different permutations of IP version availability would all result in connecting to the same FQDN = the first one with an address that's compatible with current connectivity, rather than the first one with an record if there is IPv6 connectivity. I'm saying we should go back and fix the specification for getaddrinfo() so that it accounts for searching. Volunteers...? If need be, yes. We should also add a AI_NOSEARCH flag so that searching is controlled directly rather than indirectly. That's what the period terminating a domain name is for. Again you confuse domain names and hostname. I've set Reply-To to ipv6@ietf.org as this is more approriate for 6man. No, it's a DNS issue, so it should go to dnsop. dnsop people: see discussion between Mark, Keith and me that started under the subject renumbering on the ietf discussion list. I chose ipv6@ietf.org (or it predecessor) because ipv6@ietf.org was where getaddrinfo()s behaviour was spec'd out. We need to at least give the 6man a chance to address it. Mark Everyone: feel free to prune some lists when you respond. :-) ___ DNSOP mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: getaddrinfo() and searching
So your issue that the results are inconsistent is certainly real. I'd say that the best way to avoid this is not having a search domain at all, or at the very least not several. Which is a totally unreasonable suggestion. The problem here is not the search but different stoping critera depending apon the address families supported by the host or requested by the application. Well, let's be fair. Search creates lots of problems other than this one. Right now there's not really any way to unambiguously specify a FQDN that works across all applications, has the same meaning across all applications, and has the same meaning independent of what host the query is being made from. That's a real problem. Yes, users like search, but it's arguably a Bad Idea, particularly in the absence of a universal syntax that says don't subject this name to search. IMHO the stopping criterion should be that if there are _any_ RRs matching the name in a particular zone, the search should terminate. We need a new DNS rcode or universal deployment of DNSSEC to support that in the DNS or make ANY queries on NODATA. A NODATA response does *not* indicate some rdata. Stoping on NODATA might be feasible but you need to look at all the possible backends. We wrote a API that failed to account for the usual use senario. In fact the guidance in there is the direct opposite of what should be done with the usual use senario. The usual use scenario is broken, and it's based on a previous poorly-designed API. It perfectly fine for a MTA which get fully qualified names in MX records then looks up the addresses. MTA's should be disabling name searching in the resolver. That however is not how most application work nor how the users of those applications want them to work. They want to be able to search. I've actually had requests to extend the number if domains that can be in the search list. I think you're grossly overgeneralizing here. Email is far from the only application that needs for DNS names to be unambiguous. And users would benefit from having DNS names being used consistently from one app to another, even though they may not realize this. MTA's get FQHN from MX records. They don't need to search. It's the MUA's job to qualify mail domains. The MTA should be being given FQMD's. I'm sure there are other applications that only take fully qualified names, however most applications take unqalified names. People like to use unqualified *and* partially qualified hostnames. People also like to drive without seat belts. We don't let them do that either... Or at least, we don't listen to their complaints when the results are inferior to those obtained while driving _with_ a seatbelt. We also put air bags in cars to help those that don't use saftey belts. Maybe the equivalent of air bags in the case of DNS lookups would be having an API that refused to search any name containing a .. I can hear the screams now. However it would make the implementations simpler. I don't think any vendor will stop supporting partially qualified names without a RFC prohibiting it. Mark Keith IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: getaddrinfo() and searching
On 25-sep-2007, at 2:18, Mark Andrews wrote: You are comingling way too many things here. Let me simply conclude that foo.example.org is the first name that is tried and since it exists what comes back for that name is what's going to be used. Actually it isn't specified what should happen. If you don't make queries most(all?) existing search algorithms will continue to foo.example.net. Remember, in the DNS, a name can exist yet have not records associated with it (rcode=NOERROR ancount=0 is returned for all types). Looks like you're right, at least as far as my Mac is concerned. I set up two subdomains test1 and test2 with each the hosts a, b, c and d with the following addresses: IPv6 IPv4 a.test1 X X b.test1 X - c.test1 - X d.test1 - - a.test2 - - b.test2 - X c.test2 X - d.test2 X X Then I set up test1.runningipv6.net, test2.runningipv6.net up as my search domains. (Info is still in there, feel free to try for yourself. TTL is 20 seconds.) Results on my Mac running the latest updates with both IPv4 and IPv6 connectivity: (host talks directly to the DNS and looks for both A and ) $ host a a.test1.runningipv6.net has address 192.0.2.101 a.test1.runningipv6.net has IPv6 address 2001:db8:1::a $ host b b.test1.runningipv6.net has IPv6 address 2001:db8:1::b $ host c c.test1.runningipv6.net has address 192.0.2.103 $ host d d.test2.runningipv6.net has address 192.0.2.204 d.test2.runningipv6.net has IPv6 address 2001:db8:2::d (traceroute only does IPv4) $ traceroute a traceroute to a.test1.runningipv6.net (192.0.2.101), 64 hops max, 40 byte packets $ traceroute b traceroute to b.test2.runningipv6.net (192.0.2.202), 64 hops max, 40 byte packets $ traceroute c traceroute to c.test1.runningipv6.net (192.0.2.103), 64 hops max, 40 byte packets $ traceroute d traceroute to d.test2.runningipv6.net (192.0.2.204), 64 hops max, 40 byte packets (traceroute6 only does IPv6) $ traceroute6 a traceroute6 to a.test1.runningipv6.net (2001:db8:1::a) from $ traceroute6 b traceroute6 to b.test1.runningipv6.net (2001:db8:1::b) from $ traceroute6 c traceroute6 to c.test2.runningipv6.net (2001:db8:2::c) from $ traceroute6 d traceroute6 to d.test2.runningipv6.net (2001:db8:2::d) from (telnet does both IPv4 and IPv6) $ telnet a Trying 2001:db8:1::a... $ telnet b Trying 2001:db8:1::b... $ telnet c Trying 2001:db8:2::c... $ telnet d Trying 2001:db8:2::d... So your issue that the results are inconsistent is certainly real. I'd say that the best way to avoid this is not having a search domain at all, or at the very least not several. Which is a totally unreasonable suggestion. The problem here is not the search but different stoping critera depending apon the address families supported by the host or requested by the application. We wrote a API that failed to account for the usual use senario. In fact the guidance in there is the direct opposite of what should be done with the usual use senario. It perfectly fine for a MTA which get fully qualified names in MX records then looks up the addresses. MTA's should be disabling name searching in the resolver. That however is not how most application work nor how the users of those applications want them to work. They want to be able to search. I've actually had requests to extend the number if domains that can be in the search list. If someone wants to spend time to come up with a reasonable guideline of how to behave that gives the same results regardless of the type of connectivity that's available, that would be good but probably extremely hard to do. People like to use unqualified *and* partially qualified hostnames. People also like to drive without seat belts. We don't let them do that either... Or at least, we don't listen to their complaints when the results are inferior to those obtained while driving _with_ a seatbelt. We also put air bags in cars to help those that don't use saftey belts. I'm saying we should go back and fix the specification for getaddrinfo() so that it accounts for searching. Make the optimisation of not looking for A/ record only occur when searching is disabled. Make the queries for both types manditory when searching. This will cause getaddinfo() to return consistant results. We should also add a AI_NOSEARCH flag so that searching is controlled directly rather than indirectly. The lack of a AI_NOSEARCH define would mean the application would use the indirect method. Mark I've set Reply-To to ipv6@ietf.org as this is more approriate for 6man
Re: prefix length determination for DHCPv6
A fixed length network portion is also simpler and easier to=20 administer and operate if you have the opportunity, which is=20 why I'm an advocate for /48s for nearly everybody. Leaving=20 the problems of dealing with the complexity of variable=20 length prefixes to the expert employees of the network=20 service providers, not their customers, makes good sense to me. Again, I think people who've worked with Novell IPX or=20 Appletalk would also agree. Then you need to get involved in setting RIR policy because this concept of the fixed /48 network size is already starting to disappear. Nobody from the IETF was available to explain why the designers of IPv6 intended for /48 to be the fixed length network size when ARIN passed a policy to allow ISPs to allocate /56s to consumer customers. Even though the ARIN decision was not a bad one, unless better understanding of the IPv6 design is communicated, then the /48 boundary will fade away and everyone will have to renumber their networks when they change providers. --Michael Dillon While end sites are expected to be given a /48, that was expected to be divided into 65536 subnets of /64. Whether you used all the 65536 subnets didn't matter. It was enough subnets to cover all but the very large enterpises. Even if you needed more it should not be a real issue for ISP's to supply you with a /47 to give you 131072 subnets. Moving ISPs should still be easy as you are only equivalent to two customers. I suspect with /56 there will end up being a reasonable number of exception customers. Enough I suspect that ISP's will maintain two pools. One for /56's and one for /48's. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
Thus spake Mark Andrews [EMAIL PROTECTED] The alternative is to renumber the entire network every time a link goes up or down. No. You don't have to renumber. You just have to deprecate the addresses associated with the downed link. This is the sort of thing routers should be able to do automatically. Are the routers going to summon all the affected folks to a change control meeting, verify the approvals, do the necessary post-change testing, etc? Are they going to update all the firewall configs, DNS, etc? There are no firewall changes to make. There are no DNS changes to make. Just because a prefix is deprecated it doesn't suddenly become invalid. When the link is restored the prefix will be reinstated. Do multi-homing NAT boxes in the IPv4 world cause a change control meeting? All this is doing is moving the source address selection from boxes in the middle of the network to the edge nodes. Even the above automatic address deprecation part isn't available yet, despite a decade of folks claiming that renumbering is easy, and that's not even the hard part. We are not talking about renumbering. We are talking about address selection. All the boxes will continue to have all the addresses before, during and after the link down event. Most of the operational and innovation costs of NAT are also present with a stateful firewall, which any sane organization will be using, because it's really the stateful inspection that burns you. NAT introduces costs above and beyond those of a stateful firewall. That's like saying having a broken leg is an additional cost above and beyond the cost of death. Not breaking your leg doesn't make you any less dead. So you don't think have packets change addresses and ports as they cross the NAT is not a additional cost especially for humans trying to diagnose problem? It definitely much easier to see traffic flows on two sided of a box if you don't have to also match different address and ports. And as for stateful firewalls, applications should be able to talk to them to open up reply traffic if needed. Yeah, try to sell that to any enterprise security department. It's the applications and users that security folks are trying to protect their networks from in the first place, and internal users are a much, much bigger threat to security than external folks are. That is why the firewall should be on the node and not in the middle of the network. Every box protects itself from every other box including internal boxes. Again, RFC 4192 ignores all of the non-technical aspects of renumbering. That's probably appropriate, given the IETF's domain, but it's only a tiny part of what must be done. Changing the address on an interface takes a few seconds; the change control processes leading up to it can burn months of manpower. Real renumbering events are rare. That all depends what you call real. Any event that breaks connectivity (including established connections) for more than a few seconds is real to me. I said renumbering events not link outages. If you don't have a routing slot for the prefix you are using, which describes PA addresses, then nothing a end site can do will prevent established connections from failing if the link to where the covering prefix traffic is sent fails. You are wanting NAT to provide multi-homing support. This does not require you to renumber. There is no need to use NAT for this with IPv6. IPv6 provides the mechanisms to move the source address selection back to the end host (where it belongs). For the record, I hate NAT, for all the reasons that most of IETFers do. What I'm saying is that NAT is considered by the market to be less evil than the alternatives the IETF has proposed to date. Until folks recognize that, no progress will be made. I'd much prefer to see widespread use of PI space, and significant effort put into an id/loc split scheme so that the DFZ doesn't implode as a result. OTOH, router vendors are claiming the ability to support two million routes today and ten million in a few years, so we have time to work on that. Well until that comes along, providing a multi-homing solution that will work with existing without resorting to NAT is something we should be striving for. If there are pieces missing we should be indentifying them and getting vendors to implement them. As for using multiple PA about the only thing I see missing is detection of the trigger events (link down). IPv6 has a different management paradigm to IPv4. Education is important. S Stephen Sprunk Those people who think they know everything
