Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
Hi Dan, Inline please, 2011/9/27 Dan Wing dw...@cisco.com -Original Message- From: Hui Deng [mailto:denghu...@gmail.com] Sent: Monday, September 26, 2011 11:01 PM To: Dan Wing Cc: teemu.savolai...@nokia.com; satoru.matsush...@gmail.com; ietf@ietf.org; softwi...@ietf.org; beh...@ietf.org Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard Hi Dan inline please, I believe the objection is against non-deterministic translation, rather than stateful versus stateless. By non-deterministic, I mean that the subscriber's equipment (e.g., CPE) cannot determine the mapping it will have on the Internet. A+P mechanisms are Could you help be more elaboration on CPE can't determine the ampping? It can't determine the public IP address and port of a mapping on the NAT64 (CGN), and it can't create a mapping on the NAT64 (CGN) -- because the CGN is going to make a dynamic mapping when it sees a UDP, TCP, or ICMP packet from the subscriber. I don't see it matters deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). By the way, I would say you are missing one early draft: http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00 which is align with 4rd about 4v6 translation which has been contributed by major operators which is also align with NAT64 deployment. Sorry. -d -Hui A stateful CGN, as commonly deployed, is not deterministic. However -- and this is my point in this email -- a stateful CGN can be configured and deployed so that it deterministically maps traffic. That is, it can function very much like A+P/4rd/Dual- IVI so that port N from subscriber A is always mapped to public port Z on IPv4 address Y. We could have the CPE know about that fixed mapping using the same DHCP options that A+P/4rd/ Dual-IVI would use, or use PCP, or use some other protocol. -d I would assume softwires follows these same IETF guidelines and therefore is now focusing solely on stateless approaches(?). If the IETF opinion has changed so that also stateful double translation solutions are now ok for IETF, then that should perhaps be reflected in this document as well. Unfortunately, I did not have chance to go to softwires interim, but please let us know if the discussions there impact also the quoted recommendation. Best regards, Teemu -Original Message- From: behave-boun...@ietf.org [mailto:behave- boun...@ietf.org] On Behalf Of ext Satoru Matsushima Sent: 13. syyskuuta 2011 06:51 To: ietf@ietf.org Cc: beh...@ietf.org; Satoru Matsushima Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard The introduction in the draft says: IETF recommends using dual-stack or tunneling based solutions for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]. This statement makes a strong obstacle when we develop stateless solution with translation in softwires wg. I think that it is still remained a room to make decision whether removing the statement or remaining it. The discussion which we'll have in the softwires interim meeting would be helpful to decide it. Best regards, --satoru On 2011/08/31, at 22:53, The IESG wrote: The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Dual Stack Hosts Using Bump-in-the-Host (BIH)' draft-ietf-behave-v4v6-bih-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6
Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
inline please, 2011/9/27 Dan Wing dw...@cisco.com -Original Message- From: teemu.savolai...@nokia.com [mailto:teemu.savolai...@nokia.com] Sent: Monday, September 26, 2011 11:14 PM To: dw...@cisco.com; satoru.matsush...@gmail.com; ietf@ietf.org Cc: softwi...@ietf.org; beh...@ietf.org Subject: RE: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard I believe the objection is against non-deterministic translation, rather than stateful versus stateless. By non-deterministic, I mean that the subscriber's equipment (e.g., CPE) cannot determine the mapping it will have on the Internet. A+P mechanisms are deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). A stateful CGN, as commonly deployed, is not deterministic. I don't understand why that is significant enough factor for IETF to (not) recommend some double translation variants. I mean does existing applications work better if double translation is done in deterministic manner? Yes, it allows the CPE to implement an ALG -- if an application needs an ALG (e.g., active-mode FTP). Are you saying distrbiuted ALG is much better than centralized ALG? -Hui -d One reasoning against double translation has been that it breaks some class of applications. Is it now so that some forms of double translation do not break applications while some others do? Teemu ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Hi, So, with more detailed comments below, I think the key thing I'm still struggling with finding a way to articulate is the distinction between: . assignment/(re)delegation of responsibility . offloading work I think the proposal addresses the second. I believe the real problem is that the responsibility for the organization for which the person is ex-officio member is not readily reassigned *from* the person who is in the hotseat. We can agree it would be good if it *could* be done -- it would be good if the IAB Chair (for eg) was not the best/only person to know the nuances of all things going on in the IAB's space. But I don't believe we get there by pulling them out of the loop of administration (with only observer seat status). A few follow-ups, in-line: On 9/20/11 3:05 PM, John C Klensin wrote: --On Tuesday, September 20, 2011 14:16 -0400 Leslie Daigle les...@thinkingcat.com wrote: Hi, I had the comments below on a previous incarnation of how to fix the IAOC because Chairs are overloaded. I have to say -- I don't think the substantive points are addressed in the new proposal, which leaves the Chairs as spectators to the IAOC process. I don't think you can disagree with me that, with no vote (recognized voice) in a committee's work, there's even less possibility to find the hours to keep up with the substance of discussions and thus be able to contribute meaningfully to a discussion when the time comes. As ex-officio non-voting members, with the main responsibility for representing IAB and IESG views and needs resting with someone else, that seems ok to me. At the same time, I think you underestimate the ability of the people involved to read in really quickly if that is necessary/ important. I think I disagree about the likelihood of that working. Often times, the important thing is to detect there is an issue to address. Substantively -- this takes the Chairs off the IAOC, just as the original proposal did, and my comments/confusion/questions below are still current for me. I think I responded to most of these in a different subthread earlier this week. The remarks below are just a quick summary. Original Message Subject: Re: I-D Action:draft-klensin-iaoc-member-00.txt Date: Tue, 01 Sep 2009 18:06:07 -0400 From: Leslie Daigleles...@thinkingcat.com To: IETF discussion listietf@ietf.org CC: John C Klensinklen...@jck.com I'm having troubles reconciling a couple of things: 1/ Recent discussion (different draft) on the importance of the IAOC implementing IETF (and IAB) policy and admin requirements; not having the IAOC *setting* those requirements; 2/ Suggesting that the IAB IETF Chairs should not be on the IAOC. Leslie, You appear to be assuming that the proposal is somehow removing the IAB and IESG (and ISOC) representation/ presence on the IAOC and Trust. No one has suggested that. I recognize that is not the intent, but I am suggesting that is what will happen in practice. Especially since, at some point, an IAB or an IESG will decide it's politically correct to have a representative who is not currently serving as a member of the IESG or IAB. What has been suggested is that the determination of who is most able to effectively represent those bodies can sensibly be left up to them rather than assuming that the Chairs are somehow endowed with special knowledge and wisdom that no one else shares. Well, speaking only for myself, I think if they were truly wise, they would not find themselves sitting in the chair seat ;-) Rather than thinking the individuals are especially gifted, I believe they have more of the cross-breadth of information than any other committee member AND they wear the responsibility, like no other member does. I think it would be really stupid for the IESG, IAB, or ISOC leadership to put someone on the IAOC who wasn't thoroughly familiar with the thinking in those bodies about IASA issues and competent in the issues the IAOC and Trust address. I think we can trust those bodies to avoid being stupid (except possibly as a tradeoff against worse choices) and don't need to invent rules that ban stupidity. As it stands the IETF Chair is in a unique position to understand all the requirements of the IETF community and IETF administrative activities. There isn't someone else who can step in: all other IESG members are tasked, as a primary responsibility, with looking after their particular areas. Sometimes I feel as if the IETF Chair is tasked with doing a good Superman imitation -- understanding everything, knowing everything, leaping tall buildings... Despite my frequent role as a critic, I'm also impressed with how good a job recent incumbents have done at that. I agree on all points -- and have said in other contexts that I think it's a significant challenge for the IETF that it is more or less held hostage to being able to find such superman every 2, 4 or 6
Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
On Sep 28, 2011 2:51 AM, Hui Deng denghu...@gmail.com wrote: Hi Dan, Inline please, 2011/9/27 Dan Wing dw...@cisco.com -Original Message- From: Hui Deng [mailto:denghu...@gmail.com] Sent: Monday, September 26, 2011 11:01 PM To: Dan Wing Cc: teemu.savolai...@nokia.com; satoru.matsush...@gmail.com; ietf@ietf.org; softwi...@ietf.org; beh...@ietf.org Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard Hi Dan inline please, I believe the objection is against non-deterministic translation, rather than stateful versus stateless. By non-deterministic, I mean that the subscriber's equipment (e.g., CPE) cannot determine the mapping it will have on the Internet. A+P mechanisms are Could you help be more elaboration on CPE can't determine the ampping? It can't determine the public IP address and port of a mapping on the NAT64 (CGN), and it can't create a mapping on the NAT64 (CGN) -- because the CGN is going to make a dynamic mapping when it sees a UDP, TCP, or ICMP packet from the subscriber. I don't see it matters +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Cb deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). By the way, I would say you are missing one early draft: http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00 which is align with 4rd about 4v6 translation which has been contributed by major operators which is also align with NAT64 deployment. Sorry. -d -Hui A stateful CGN, as commonly deployed, is not deterministic. However -- and this is my point in this email -- a stateful CGN can be configured and deployed so that it deterministically maps traffic. That is, it can function very much like A+P/4rd/Dual- IVI so that port N from subscriber A is always mapped to public port Z on IPv4 address Y. We could have the CPE know about that fixed mapping using the same DHCP options that A+P/4rd/ Dual-IVI would use, or use PCP, or use some other protocol. -d I would assume softwires follows these same IETF guidelines and therefore is now focusing solely on stateless approaches(?). If the IETF opinion has changed so that also stateful double translation solutions are now ok for IETF, then that should perhaps be reflected in this document as well. Unfortunately, I did not have chance to go to softwires interim, but please let us know if the discussions there impact also the quoted recommendation. Best regards, Teemu -Original Message- From: behave-boun...@ietf.org [mailto:behave- boun...@ietf.org] On Behalf Of ext Satoru Matsushima Sent: 13. syyskuuta 2011 06:51 To: ietf@ietf.org Cc: beh...@ietf.org; Satoru Matsushima Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard The introduction in the draft says: IETF recommends using dual-stack or tunneling based solutions for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]. This statement makes a strong obstacle when we develop stateless solution with translation in softwires wg. I think that it is still remained a room to make decision whether removing the statement or remaining it. The discussion which we'll have in the softwires interim meeting would be helpful to decide it. Best regards, --satoru On 2011/08/31, at 22:53, The IESG wrote: The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Dual Stack Hosts Using Bump-in-the-Host (BIH)' draft-ietf-behave-v4v6-bih-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-14. Exceptionally, comments
Re: IAOC: delegating ex-officio responsibility
Brian: And to be clear, I (still the previous IETF Chair) think that some such change is needed, which is exactly why I wrote the above draft in 2006. Perhaps the difference is that I see the IAOC/Trust role as very hard to separate from the IETF Chair role - but more easily separable from the IESG Chair role. This is not my experience. There have been some decisions related to meetings where the IAOC and the IESG need to be in alignment. The last two IAB Chairs have not been active ex-officio members of the IESG, and they have let the liaisons between the IAB and the IESG cover these responsibilities. As a result, I have been the only IAOC member with insight into the IESG. This has been importing in these matters. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
-Original Message- From: Hui Deng [mailto:denghu...@gmail.com] Sent: Wednesday, September 28, 2011 2:52 AM To: Dan Wing Cc: teemu.savolai...@nokia.com; satoru.matsush...@gmail.com; ietf@ietf.org; softwi...@ietf.org; beh...@ietf.org Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard inline please, 2011/9/27 Dan Wing dw...@cisco.com -Original Message- From: teemu.savolai...@nokia.com [mailto:teemu.savolai...@nokia.com] Sent: Monday, September 26, 2011 11:14 PM To: dw...@cisco.com; satoru.matsush...@gmail.com; ietf@ietf.org Cc: softwi...@ietf.org; beh...@ietf.org Subject: RE: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard I believe the objection is against non-deterministic translation, rather than stateful versus stateless. By non-deterministic, I mean that the subscriber's equipment (e.g., CPE) cannot determine the mapping it will have on the Internet. A+P mechanisms are deterministic (including 4rd, Dual-IVI, and draft-ymbk-aplus-p). A stateful CGN, as commonly deployed, is not deterministic. I don't understand why that is significant enough factor for IETF to (not) recommend some double translation variants. I mean does existing applications work better if double translation is done in deterministic manner? Yes, it allows the CPE to implement an ALG -- if an application needs an ALG (e.g., active-mode FTP). Are you saying distrbiuted ALG is much better than centralized ALG? Best is no ALG. Worse is one ALG. Even worse is two ALGs. -d -Hui -d One reasoning against double translation has been that it breaks some class of applications. Is it now so that some forms of double translation do not break applications while some others do? Teemu ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
-Original Message- From: Cameron Byrne [mailto:cb.li...@gmail.com] Sent: Wednesday, September 28, 2011 8:16 AM To: Hui Deng Cc: softwi...@ietf.org; beh...@ietf.org; teemu.savolai...@nokia.com; ietf@ietf.org; Dan Wing Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard On Sep 28, 2011 2:51 AM, Hui Deng denghu...@gmail.com wrote: Hi Dan, Inline please, 2011/9/27 Dan Wing dw...@cisco.com -Original Message- From: Hui Deng [mailto:denghu...@gmail.com] Sent: Monday, September 26, 2011 11:01 PM To: Dan Wing Cc: teemu.savolai...@nokia.com; satoru.matsush...@gmail.com; ietf@ietf.org; softwi...@ietf.org; beh...@ietf.org Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard Hi Dan inline please, I believe the objection is against non-deterministic translation, rather than stateful versus stateless. By non- deterministic, I mean that the subscriber's equipment (e.g., CPE) cannot determine the mapping it will have on the Internet. A+P mechanisms are Could you help be more elaboration on CPE can't determine the ampping? It can't determine the public IP address and port of a mapping on the NAT64 (CGN), and it can't create a mapping on the NAT64 (CGN) -- because the CGN is going to make a dynamic mapping when it sees a UDP, TCP, or ICMP packet from the subscriber. I don't see it matters +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Can you run an FTP server on the BIH host, and have it do active mode transfers and passive mode transfers? I admit that isn't terribly important (nobody much loves FTP any more), but if the BIH host doesn't know its public mapping and can't create one, we lose that class of applications that listen on a port. Losing that class of applications may, or may not, be important. Many of those applications do STUN or STUN-/ICE-like things for their own NAT traversal (e.g., Skype). But some don't and work properly without a hole punched (e.g., BitTorrent). PCP can make all of this work, if it's integrated into BIH and the NAT64. -d Cb deterministic (including 4rd, Dual-IVI, and draft-ymbk- aplus-p). By the way, I would say you are missing one early draft: http://tools.ietf.org/html/draft-murakami-softwire-4v6- translation-00 which is align with 4rd about 4v6 translation which has been contributed by major operators which is also align with NAT64 deployment. Sorry. -d -Hui A stateful CGN, as commonly deployed, is not deterministic. However -- and this is my point in this email -- a stateful CGN can be configured and deployed so that it deterministically maps traffic. That is, it can function very much like A+P/4rd/Dual- IVI so that port N from subscriber A is always mapped to public port Z on IPv4 address Y. We could have the CPE know about that fixed mapping using the same DHCP options that A+P/4rd/ Dual-IVI would use, or use PCP, or use some other protocol. -d I would assume softwires follows these same IETF guidelines and therefore is now focusing solely on stateless approaches(?). If the IETF opinion has changed so that also stateful double translation solutions are now ok for IETF, then that should perhaps be reflected in this document as well. Unfortunately, I did not have chance to go to softwires interim, but please let us know if the discussions there impact also the quoted recommendation. Best regards, Teemu -Original Message- From: behave-boun...@ietf.org [mailto:behave- boun...@ietf.org] On Behalf Of ext Satoru Matsushima Sent: 13. syyskuuta 2011 06:51 To: ietf@ietf.org Cc: beh...@ietf.org; Satoru Matsushima Subject: Re: [BEHAVE] Last Call: draft-ietf-behave- v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard The introduction in the draft says: IETF recommends using dual-stack or tunneling based solutions for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180].
Re: [Softwires] [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
+1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/ - Mark ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Softwires] [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley m...@townsley.net wrote: +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/ - Mark We're still doing that, and IPv6-only is still my philosophical preference and that is how we are launching the IPv6 + NAT64/DNS64 service into the production mobile network (real soon now). No change in that path. But some power users wanted their IPv4-only applications like Skype to work so they coded a NAT46 work-around for the N900. It is clever, it works. Their process of feeling the pain of a very few pesky IPv4-only apps and working around it is all documented here: http://talk.maemo.org/showthread.php?t=60320 Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D In the end (as well as IPv6-only near term in mobile), IP version agnostic apps will prove to be more reliable and therefore will get more market share. Cameron ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Softwires] [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
On Sep 28, 2011, at 2:12 PM, Cameron Byrne wrote: In the end (as well as IPv6-only near term in mobile), IP version agnostic apps will prove to be more reliable and therefore will get more market share. Not clear. There's a tradeoff between the additional reliability of being version-agile, and the decreased reliability associated with hacks, proxies, relays, etc. needed to make the application work under NATted v4 at all. That tradeoff will be different for different kinds of applications. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
On Wed, Sep 28, 2011 at 11:20 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Hi Cameron, Very interesting ( clever indeed). How does this clever code ensure that all but a few (pesky apps) continue to use IPv6 interface instead of the NAT46 interface? Rajiv, DNS64 is used. So anything that can take a will use a and the native IPv6 path, with or without NAT64 -- as needed. If the application itself delivers an IPv4 literal via protocols like MSN or Skype, there is a path and socket made available, that is what this NAT46 code does. As i mentioned before, i don't like this. But, i respect that it works and it solves a real problem for users of these ipv4-only apps. I personally find it easy to live with only IP version agnostic apps that work well in an IPv6-only NAT64/DNS64 network. I have been eating this dog food for over 18 months. I am happy to let the market and eco-system punish apps for not supporting IPv6, and for the market to reward apps that do support IPv6. I believe draft-ietf-behave-v4v6-bih-06 has too narrow of a scope to be useful since it explicitly does NOT support IPv4-only apps talking to IPv4 servers over an IPv6-only network Cameron Cheers, Rajiv -Original Message- From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On Behalf Of Cameron Byrne Sent: Wednesday, September 28, 2011 2:12 PM To: Mark Townsley Cc: Hui Deng; Softwires-wg list; Behave WG; IETF Discussion; Dan Wing (dwing) Subject: Re: [BEHAVE] [Softwires] Last Call: draft-ietf-behave-v4v6-bih- 06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley m...@townsley.net wrote: +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/ - Mark We're still doing that, and IPv6-only is still my philosophical preference and that is how we are launching the IPv6 + NAT64/DNS64 service into the production mobile network (real soon now). No change in that path. But some power users wanted their IPv4-only applications like Skype to work so they coded a NAT46 work-around for the N900. It is clever, it works. Their process of feeling the pain of a very few pesky IPv4-only apps and working around it is all documented here: http://talk.maemo.org/showthread.php?t=60320 Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D In the end (as well as IPv6-only near term in mobile), IP version agnostic apps will prove to be more reliable and therefore will get more market share. Cameron ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
On 2011-09-29 04:24, Russ Housley wrote: Brian: And to be clear, I (still the previous IETF Chair) think that some such change is needed, which is exactly why I wrote the above draft in 2006. Perhaps the difference is that I see the IAOC/Trust role as very hard to separate from the IETF Chair role - but more easily separable from the IESG Chair role. This is not my experience. There have been some decisions related to meetings where the IAOC and the IESG need to be in alignment. The last two IAB Chairs have not been active ex-officio members of the IESG, and they have let the liaisons between the IAB and the IESG cover these responsibilities. As a result, I have been the only IAOC member with insight into the IESG. This has been importing in these matters. Yes, there's no doubt that the IESG needs to have strong input into IASA decisions; there is no way round that. But it isn't clear to me that this must be the IESG Chair's job, if we had a model where the IETF Chair and IESG Chair were two different people. As long as it's one person, this is a zero-sum game. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Yes, there's no doubt that the IESG needs to have strong input into IASA decisions; there is no way round that. But it isn't clear to me that this must be the IESG Chair's job, if we had a model where the IETF Chair and IESG Chair were two different people. As long as it's one person, this is a zero-sum game. It seems to me that the basic problem with this whole argument is that you can't force people to pay attention by making rules, particularly if the attention shortage is due to lack of time rather than lack of interest. I would rather have somebody show up at my meetings who has delegated authority, enough time to pay attention and think about the issues, and a good working relationship with the chair than insist that a harried chair call in and mute his phone so everyone one else can't hear that he's answering e-mail about all the other stuff he has to do. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
On 09/28/2011 17:55, John Levine wrote: I would rather have somebody show up at my meetings who has delegated authority, enough time to pay attention and think about the issues, and a good working relationship with the chair than insist that a harried chair call in and mute his phone so everyone one else can't hear that he's answering e-mail about all the other stuff he has to do. Fortunately those are not the only 2 options. :) I've followed this thread with interest, but haven't spoken up because I was not sure what the right answer was. I'm still not, but ... I am opposed to the current proposal. However I think that the symptoms Olaf has described are worth serious consideration. So I am in favor of what several people a lot smarter than me have already proposed, which is taking a step back and seriously examining: 1. What the chairs are *required* to do, 2. What they currently are doing, 3. and whether changes to 1 and/or 2 are necessary. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
All, I propose to completely remove section 5 of this draft. The reason: The IETF should *NOT* document any comment on any multiple standards developed by other SDOs which are outside of the IETF's scope. Especially standards like like SONET/SDH, CDMA/GSM. The current text reflects the author's impressions, and since I don't believe that the authors were involved in the debates when these standards were developed, they *DO NOT KNOW ENOUGH* to comment authoritatively on them. The IETF should refrain from documenting things that might offend other SDOs concerning standards issues in which IETF was or is not involved. Best regards, Huub. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-grow-no-more-unallocated-slash8s-03.txt (Time to Remove Filters for Previously Unallocated IPv4 /8s) to BCP
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Time to Remove Filters for Previously Unallocated IPv4 /8s' draft-ietf-grow-no-more-unallocated-slash8s-03.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-10-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract It has been common for network administrators to filter IP traffic from and BGP prefixes of unallocated IPv4 address space. Now that there are no longer any unallocated IPv4 /8s, this practise is more complicated, fragile and expensive. Network administrators are advised to remove filters based on the registration status of the address space. This document explains why any remaining packet and BGP prefix filters for unallocated IPv4 /8s should now be removed on border routers and documents those IPv4 unicast prefixes that should not be routed across the public Internet. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-grow-no-more-unallocated-slash8s/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-grow-no-more-unallocated-slash8s/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'PIM Multi-Topology ID (MT-ID) Join Attribute' to Proposed Standard (draft-ietf-pim-mtid-10.txt)
The IESG has approved the following document: - 'PIM Multi-Topology ID (MT-ID) Join Attribute' (draft-ietf-pim-mtid-10.txt) as a Proposed Standard This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pim-mtid/ Technical Summary This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. Thus, this document facilitates the support of multi-topology PIM. Working Group Summary Nothing special to note. There is consensus within the PIM WG to publish the document. The participation has been with individuals from a variety of vendors and providers. Document Quality The document has undergone thorough review by the IETF's multicast community. A series of updates were made after AD review. At least one implementation of this extension exists. Personnel Mike McBride (mmcbr...@cisco.com) is the Document Shepherd. Adrian Farrel (adr...@olddog.co.uk) is the Responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IETF 82 - Hotel Reservations - REMINDER
82nd IETF Meeting Taipei, Taiwan November 13-18, 2011 Host: Taiwan Network Information Center (TWNIC) Host Website: http://ietf82.tw/ Meeting venue: Taipei International Convention Center (TICC) http://www.ticc.com.tw/index_en.aspx Register online at: http://www.ietf.org/meetings/82/ 1. Registration 2. Visas Letters of Invitation 3. Accommodations 4. Host City Special Offer 5. Companion Program 1. Registration A. Early-Bird Registration - USD 650.00 Pay by Friday, 11 November 2011 1700 PT (00:00 UTC) B. After Early-Bird cutoff - USD 800.00 C. Full-time Student Registrations - USD 150.00 (with proper ID) D. One Day Pass Registration - USD 350.00 E. Registration Cancellation Cut-off for registration cancellation is Monday, 07 November 2011 at 1700 PT ( UTC). Cancellations are subject to a 10% (ten percent) cancellation fee if requested by that date and time. F. Online Registration and Payment ends Friday, 11 November 2011, 1700 local Taipei time. G. On-site Registration starting Sunday, 13 November 2011 at 1100 local Taipei time. 2. Visas Letters of Invitation: Information on Visiting Taiwan, please visit: http://ietf82.tw/info.html#h1 and http://www.boca.gov.tw/np.asp?ctNode=529mp=2 After you complete the registration process, you will be given the option of requesting a Letter of Invitation. You can request the Letter of Invitation as soon as you finish registration, or at a later time by following the link provided in the confirmation email. 3. Accommodations - Please note cutoff dates The IETF is holding blocks of guest rooms at 3 hotels in Taipei: Grand Hyatt Taipei (Headquarter Hotel - adjacent to the TICC and approximately a 3 minute walk); Grand Room (single): NTD 7,000; USD 239; EUR 166; JPY 18,346 Shangri-La Far Eastern Plaza Hotel (Overflow Hotel - approximately 5-10 minute taxi ride, it is not accessible by walking, shuttle to TICC daily at 8:15 AM with reservation); Deluxe Room (single): NTD 6,300; USD 215; EUR 150; JPY 16,511 Howard Plaza Hotel (Overflow Hotel - approximately 10 minute taxi ride, approximately a 30 minute walk, accessible by subway and bus) Superior Room (single): NTD 4,800; USD 164; EUR 114; JPY 12,580 Room rates include one complimentary daily buffet breakfast and complimentary in-room high-speed Internet access. VAT of 5% is included in the prices, VAT rates are subject to change. 10% service charge is NOT included in the guest room rates. NOTE: Continental Breakfast will NOT be served at the meeting venue since it is included in the guest room rate at the hotels IETF is holding a block. Reservations Cut off Date: 12 October 2011 at the Grand Hyatt and Shangri-La, 19 October 2011 at the Howard Plaza Hotel For additional information on rates and policies, please visit: http://www.ietf.org/meeting/82/hotel.html 4. Host City Special Offer Taiwan's Bureau of Foreign Trade kindly provides all participants of international meetings held in Taipei (including IETF 82) a MEET TAIWAN CARD, which offers free wireless Internet service and various discounts for shopping, dining, accommodation, transportation, leisure, entertainment, communication, and other services during the meeting. The MEET TAIWAN CARD is free of charge. For more details, please visit http://card.meettaiwan.com/welcome.aspx You can also access this information through the Host's Web Page at: http://ietf82.tw/ For those who need free wireless Internet service, we would like to recommend to apply one as soon as possible. 5. Companion Program If you are traveling with a friend or family member over 18 years of age you can register them for the IETF Companion Program for only USD 15.00 Benefits include: - A special welcome reception for companions from 1630-1730 on Sunday, 13 November - Ability to attend the official Welcome Reception from 1700-1900 on Sunday, 13 November - A distinctive meeting badge that grants access to the venue (not to be used to attend working sessions) - Participation in a separate companion email list if you choose to help communicate and make plans with other IETF Companions. You can register your companion at any time via the IETF website or onsite at the meeting. To join the 82 companions mailing list see: https://www.ietf.org/mailman/listinfo/82companions Only 45 days until the Taipei IETF!
