RE: Last Call: (IETF meeting attendees' Frequently Asked (travel) Questions) to Informational RFC
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM > > In Section 1: > >"more efficiently than waiting until someone sends an email to the > xxattend...@ietf.org list in the days leading up to the meeting." > > The XX is ambiguous. [WEG] Well, it was intended to be generic (a variable to represent multiple numbers). Are you saying ambiguous as in "this intent is unclear, use a different method to represent this generically" or "you should use a specific number as an example, e.g. 83attend...@ietf.org"? Would "the meeting-specific attendees email list" be better? > The draft is written from am IETF perspective for an IETF audience. [WEG] It was written by an IETF person, in the IETF's process for managing documents. Within those constraints, it was meant to assume very little about what people know about IETF such that it could be useful to a non-IETF audience. If there's a point to this comment other than to be snarky, I'm missing it. > Does http://wikitravel.org/en/Paris provide answers to some of the > questions in this draft? [WEG] Probably. This draft is not about evaluating sources of information to be provided for individual and specific IETF meetings. It is meant to be generic. I'd encourage you to post that link to the Paris IETF's wiki. > "but that results in hundreds of people spending their time > searching, which is not very efficient." > > If hundreds of people spent their time searching, there would have > been more information on > http://www.ietf.org/registration/MeetingWiki/wiki/doku.php Or is it > not efficient for people to share the information they have found? [WEG] no one can force those who find an answer to their question (via whatever method) to post it to the wiki. The meeting wiki is only as good as its level of contribution, and this document isn't making commentary on that problem. This is simply noting that lots of attendees need a similar set of information. >"no matter how good online translation is getting, some of the most > informative sites may be difficult for non-native speakers to" > > Is this about informative sites being difficult for non-native > speakers or for people from a specific part of the world? [WEG] I think this is pretty self-explanatory taken in the context of the preceding sentences, but I'll attempt to clarify. When one is attempting to do research about a place one is planning to visit, if the site with the best information is only available in the local language, and half of the site is flash or graphical text buttons, sending it to translate.google is not going to translate the text contained in flash or images, which may make the site difficult or impossible to use. The source and destination language/region is immaterial. This is simply defining a practical matter associated with language barriers online. > I suggest that the author seeks feedback from people who use English as a > second language. [WEG] The author has sought and received feedback from the IETF list multiple times prior to last call, and again now. One might be forgiven for assuming that there are a few nonnative English speakers among the subscribers of said list who have read the document. If those who use English as a second language have text to provide, he'll gladly accept it. Otherwise, maligning the document or its author because it attempts to cover language issues but was written by an native English speaker is not particularly productive. > Visa requirements is a one-liner whereas food considerations are > discussed in several paragraphs. [WEG] The main posting on the IETF site regarding the specific meeting includes a link to one or more Visa information sites. IETF has been providing links to Visa information for years, as it is far more critical to foreign attendance than any of the other items discussed in this document. Therefore I didn't spend a lot of time on it. The only part of the currently-provided visa information that I have seen complaints about is when the combination of the source and destination countries' embassies don't play nicely together and Visas take too long to be practical. That is a much different problem. However, more than one person has commented about the limited text with regards to visas, so I'll attempt to bolster the Visa discussion slightly, but suggested text is welcome. Section 3.3 is labelled > International considerations. The entire document is about > international considerations. [WEG] After reviewing what is in this section based on your comment, I'd argue the other way. Like the rest of the document, a large portion of it is not specific to international travel and may vary by region and municipality within the same country. I'm open to suggestions as to an alternate heading for section 3.3 that is more descriptive than "other." Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary infor
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 10 Feb 2012, at 22:12, Chris Grundemann wrote: >> > > Are you volunteering to buy everyone on earth a new CPE? If not, who > do you suggest will? I suggest the ISPs, they are charging for the service, right? > My bet is that no one is willing to drop the > billions of dollars required - Errors cost money. They decided not to invest in IPv6, now there is time to pay. > if they were, we could just sign > everyone up for IPv6 capable CPE and skip the whole debate... ;) > > Cheers, > ~Chris For many of the reasons stated before, I think this space is not needed and I am against this proposal. Regards, /as ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03
> [RM] The intention is to use this method only for environments with native > security mechanisms, such as the Broadband Access network. You are right it > is not clearly said in the document I can add the following sentence at the > end of the introduction in order to clarify this point: > > "This mechanism is intended to be use in networks that already have native > security mechanisms that provide sufficient protection against > spoofing of DHCP traffic." It's probably worth revisiting the purpose of this mechanism. The problem that we are trying to solve is that people are reluctant to implement DHCPFORCERENEW because it's possible that an off-link attacker could more accurately guess the timing of DHCP renewal messages by first sending a DHCPFORCERENEW. The mechanism in RFC3315 (DHCPv6), which this document mirrors for DHCPv4, uses a nonce to prevent an off-link attacker from successfully triggering a renewal on a client by sending DHCPFORCERENEW; since the attacker is off-link, it doesn't have the nonce, and can't force a renewal. An on-link attacker can always simply watch the DHCP renewal message go out and respond to it, so this mechanism is useless for preventing on-link attacks, and hence the security of the nonce in the case of on-link attacks isn't relevant. So the above text isn't needed. It's possible that the document doesn't clearly document the use case for this functionality; if so, you are free to take the above paragraph, Roberta, and modify it to suit your purposes. But I am against adding the text you proposed, because it excludes the bulk of use cases for the DHCPFORCERENEW nonce mechanism. > [RM] This is because this mechanism relays on the authentication protocol > defined in section 21.5 of RFC 3315 for DHCPv6 Reconfigure and there HMAC-MD5 > is used. Essentially HMAC-MD5 is being used here to package a secret into a chunk of predictable size, and the fact that there are hacks for the mechanism isn't terribly important because the only attacker we are attempting to foil is one that doesn't have access to the cleartext or the ciphertext. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call:
John C Klensin wrote: > >Arturo Servin wrote: >> >>Chris Grundemann wrote: >>> >>> Are you volunteering to buy everyone on earth a new CPE? If >>> not, who do you suggest will? >> >> I suggest the ISPs, they are charging for the service, right? >>... >>> if they were, we could just sign >>> everyone up for IPv6 capable CPE and skip the whole debate... >>> ;) > > So, Chris, if you expect this allocation will avoid the costs of > signing everyone up for IPv6-capable CPE, what is your > transition plan? Or are you advocating an IPv4-forever model? If CPE is meant to refer to the border router, then this appears like a very short-sighted look at the real issue. There are huge amounts of equipment in use that simply does not support IPv6, other than border routers, like home multimedia and entertainment stuff (Nintendo WII, Nintendo DS, Internet-enabled set-top-boxes & TV & Radio, webcams, home NAS, etc.), which do not support IPv6, so I don't see how IPv6 could be seen as a solution at all (it isn't). So everyone who is suggesting IPv6 here, is actually suggesting NAT 4664 over NAT 444. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
> From: Arturo Servin >> Are you volunteering to buy everyone on earth a new CPE? If not, who >> do you suggest will? > I suggest the ISPs, they are charging for the service, right? Lots of CPE is actually owned by the customers, not the ISPs. E.g. in our house, both our cable modem and the router attached to it are ours. (Not quite sure how CGN would work in such an ISP - I guess they'd assign the customer's IP address, on our side of the cable modem, out of the CGN block? 'traceroute' say our cable box has a 10. address on the far side, even now.) But, anyway, telling such ISPs 'go buy new CPE' just isn't an option. > Errors cost money. They decided not to invest in IPv6, now there is > time to pay. Again, it's made cystal clear that the real goal of the opponents here is to punish people for not adopting IPv6. Don't you think this casts IPv6 in a really bad light - that the only way to get people to adopt it is to force them into it, using whatever whips and chains are available? But I'll stop there, since we're not supposed to be getting de-railed into IPv6. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
CGNs and shared space allocations (was: Re: Last Call:)
--On Monday, February 13, 2012 17:11 +0100 Martin Rex wrote: > John C Klensin wrote: >> >> Arturo Servin wrote: >>> >>> Chris Grundemann wrote: Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? >>> >>> I suggest the ISPs, they are charging for the service, >>> right? ... if they were, we could just sign everyone up for IPv6 capable CPE and skip the whole debate... ;) >> >> So, Chris, if you expect this allocation will avoid the costs >> of signing everyone up for IPv6-capable CPE, what is your >> transition plan? Or are you advocating an IPv4-forever model? > > > If CPE is meant to refer to the border router, then this > appears like a very short-sighted look at the real issue. > > There are huge amounts of equipment in use that simply does > not support IPv6, other than border routers, like home > multimedia and entertainment stuff (Nintendo WII, Nintendo DS, > Internet-enabled set-top-boxes & TV & Radio, webcams, home > NAS, etc.), which do not support IPv6, > so I don't see how IPv6 could be seen as a solution at all (it > isn't). > > So everyone who is suggesting IPv6 here, is actually > suggesting NAT 4664 over NAT 444. Martin, I think we have been over this territory before. It certainly isn't part of the current Last Call (I've changed the subject line after it got truncated). But, briefly and in the faint hope that an explanation from a slightly different perspective might help, from where I sit it looks like there are three families of IPv6 migration strategies: (1) IPv6 packets on core network, replace or upgrade end network border router to run IPv6, provide IPv6 on end network, expect all devices on end network to be IPv6-capable (either natively or dual-stack).I agree with you that this is completely unrealistic but it is also a complete strawman -- I know of no one who understands the issues who is advocating it at this point. (2) IPv6 packets on core network, replace or upgrade end network border router to be able to do protocol conversion address translation as needed so that IPv4-only devices on the LAN receive and send IPv4 packets. That border device presents public IPv6 addresses to the Internet, not (only) IPv4 addresses (public or private) There seem to be dozens of variations on this theme, with, e.g., varying ideas about what to do about IPv6-native or dual-stack devices on the LAN and whether to temporarily provide public IPv4 addresses to the Internet as well, but the two important things that all of the alternatives have in common are that a customer with IPv6-capable devices can reasonably expect to run IPv6 on them (and run them in the traditional end to end mode with other IPv6 LANs and devices) and that the translations are, at least in principle, under customer control. Note that, especially for ISPs that provide the customer boundary devices as part of their services, one of the variations is to install IPv6-only border equipment and tell customers that, if they want to continue to run IPv4-only devices, they need to obtain and install conversion boxes behind the boundary devices (possibly subsidized but basically at their own expense). I would find that approach odious, but it is no more odious than the choice faced by households with older televisions in countries (or smaller areas) that are going all-digital. Indeed, as far as I can tell, it is _exactly_ the same issue. (3) IPv6 packets possibly on ISP core networks or at peering/ exchange points, but, other than large customers who can make their own arrangements, end network border routers all speak IPv4 (more or less exclusively) and present IPv4 addresses to the network. Whatever conversions are needed occur somewhere in the middle of the network. It seems to me that there are several variations on this theme too but, if the motivation for it includes "don't change any of the equipment on the user site to be IPv6-capable" then devices on the LAN that are IPv6-capable can't take advantage of it and devices on the LAN that are IPv6-only can't operate (note the symmetry between that situation and the argument you are making). Now a problem that some of us are having with CGNs (a member of the third category but perhaps not the only one, or even only one architecture), is that it doesn't seem to inherently involve an IPv6 transition at all. Maybe there are hybrid strategies that make them an integral part of an IPv6 transition, but I'm not sure I see them. If end system LANs are going to be able to receive IPv6 packets and/or use them internally then someone is going to need to incur the cost of purchasing, installing, and supporting IPv6-capable border equipment. If avoiding the costs of that equipment change (regardless of what else the equipment could do) is a goal of a CGN-based strategy, then there is no IPv6 transition strategy, only an IPv4 preservation one (and, to me, one that reinvents many of
RE: Last Call: (IETF meeting attendees' Frequently Asked (travel) Questions) to Informational RFC
Hi, At 07:22 13-02-2012, George, Wes wrote: [WEG] Well, it was intended to be generic (a variable to represent multiple numbers). Are you saying ambiguous as in "this intent is unclear, use a different method to represent this generically" or "you should use a specific number as an example, e.g. 83attend...@ietf.org"? Would "the meeting-specific attendees email list" be better? I suggest using the example. BTW, I understand what you meant by "XX". See comment below. [WEG] It was written by an IETF person, in the IETF's process for managing documents. Within those constraints, it was meant to assume very little about what people know about IETF such that it could be useful to a non-IETF audience. If there's a point to this comment other than to be snarky, I'm missing it. You could look at the content in terms of your target audience. The draft mentions "host event organizers that may not have much familiarity with the IETF". The first two sections are more like Last Call material to give IETF participants a sense of why the draft is intended to be published as a RFC. The intent was not to be snarky. Let's assume that you are a host and you have to find the information. You can either take the points to cover "as-is" or you'll try and identify what information is important, what is useful and what is nice to have. As an example, how to get to the venue might be important; how to does one differentiate between tap water and bottled in a restaurant is nice to have. [WEG] Probably. This draft is not about evaluating sources of information to be provided for individual and specific IETF meetings. It is meant to be generic. I'd encourage you to post that link to the Paris IETF's wiki. I don't have write access to the Wiki. [WEG] no one can force those who find an answer to their question (via whatever method) to post it to the wiki. The meeting wiki is only as good as its level of contribution, and this document isn't making commentary on that problem. This is simply noting that lots of attendees need a similar set of information. I agree that the meeting wiki is only as good as the level of contribution. [WEG] I think this is pretty self-explanatory taken in the context of the preceding sentences, but I'll attempt to clarify. When one is attempting to do research about a place one is planning to visit, if the site with the best information is only available in the local language, and half of the site is flash or graphical text buttons, sending it to translate.google is not going to translate the text contained in flash or images, which may make the site difficult or impossible to use. The source and destination language/region is immaterial. This is simply defining a practical matter associated with language barriers online. To a layperson person, a "Flash" web site is as good as any other web site. I understand your point about translating content. My point was more about the information which the "average" attendee would look for. See below. [WEG] The author has sought and received feedback from the IETF list multiple times prior to last call, and again now. One might be forgiven for assuming that there are a few nonnative English speakers among the subscribers of said list who have read the document. If those who use English as a second language have text to provide, he'll gladly accept it. Otherwise, maligning the document or its author because it attempts to cover language issues but was written by an native English speaker is not particularly productive. The point was not about whether you have attempted to get feedback. I mentioned how you can get the kind of feedback to make the document more accessible to the target audience. [WEG] The main posting on the IETF site regarding the specific meeting includes a link to one or more Visa information sites. IETF has been providing links to Visa information for years, as it is far more critical to foreign attendance than any of the other items discussed in this document. Therefore I didn't spend a lot of time on it. The only part of the currently-provided visa information that I have seen complaints about is when the combination of the source and destination countries' embassies don't play nicely together and Visas take too long to be practical. That is a much different problem. However, more than one person has commented about the limited text with regards to visas, so I'll attempt to bolster the Visa discussion slightly, but suggested text is welcome. I clicked on the link on the IETF web site for visa information and I got to http://www.ietf.org/meeting/83/t-shirt-design-contest.html :-) Visa information tends to be an issue for some participants. The IAOC provides minimal information as it is not a travel agency yet. :-) As a quick comment, people might generally look for the following information: (i) Do I need a visa for the country (list of countri
RE: Last Call: (IETF meeting attendees' Frequently Asked (travel) Questions) to Informational RFC
Wes, As an additional example of "what can be done and has been done" you might want to point to http://hiroshima-info.info which is an example of a volunteer-contributed website (for IETF 76) which gives travel info from (I must admit) a "geek" perspective and from someone who has attended a lot of IETF meetings and similar events all over the world. In my view, a lot of travel information is often provided from the perspective of "locals" instead of from the perspective of "visitors" and the above example is intended to represent the latter, with a specific category of visitor. This was initially the placeholder info site for IETF76, it was later replaced (but still linked to) by the official WIDE host site. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2012-02-14 05:51, Noel Chiappa wrote: > > From: Arturo Servin > > >> Are you volunteering to buy everyone on earth a new CPE? If not, who > >> do you suggest will? > > > I suggest the ISPs, they are charging for the service, right? > > Lots of CPE is actually owned by the customers, not the ISPs. E.g. in our > house, both our cable modem and the router attached to it are ours. Sure, that's very common, but these devices are consumer electronics and will get gradually replaced by IPv6-supporting boxes as time goes on. (That is not hand-waving, the generation of boxes with IPv6 support is starting to appear.) Nobody, I think, is denying that there will be a long period of coexistence as a result. That is a separate question from this draft, which gives ISPs space for *growing* their IPv4 customer base. I think that is what upsets people. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/12/2012 13:34, Noel Chiappa wrote: > > From: Nilsson > > > there _is_ a cost, the cost of not being able to allocate unique > > address space when there is a more legitimate need than the proposed > > wasting of an entire /10 to please those who did not do the right > > thing. > > On the contrary, denying this block is likely to _accelerate_ usage of > what space remains, thereby penalizing the 'other users' whose interests > you _claim_ to be protecting. > > If an ISP can't use a shared block, they'll go ask their RIR for a block - > and given that they demonstrably have the need (lots of customers), they > will get it. Multiply than by N providers. If the RIRs do not deny these requests there is likely to be a revolt. OTOH that may be a good thing As for your other 2 options: > But it is. As I said before, the IETF has precisely two choices: > > - See CGN deployed using various hacks (e.g. squatting on space) Incredibly unlikely to happen. The ISPs are smart enough to know that this will cause them more headaches than its worth. > - See CGN deployed using a block of space allocated for that purpose If the IETF rightly denies this request then the ISPs are going to be forced to use the proper option, 1918 space. Whatever customer support costs they have to bear for the small percentage of customers that actually manage to overlap will rightly be borne by the people who created their own problems. Everyone wins. Doug -- It's always a long day; 86400 doesn't fit into a short. 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: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
> From: Doug Barton > If the RIRs do not deny these requests there is likely to be a revolt. On what grounds? The ISPs will come along and say 'I have X new customers, please give me more space for them'. The former being true, on what ground can the RIRs refuse (modulo cases like RIPE)? > If the IETF rightly denies this request then the ISPs are going to > be forced to use the proper option, 1918 space. How? The IETF has neither police, nor an army. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Feb 13, 2012, at 12:34 PM, Doug Barton wrote: >> If an ISP can't use a shared block, they'll go ask their RIR for a block - >> and given that they demonstrably have the need (lots of customers), they >> will get it. Multiply than by N providers. > > If the RIRs do not deny these requests there is likely to be a revolt. > OTOH that may be a good thing What grounds would an RIR have to deny this request? >> - See CGN deployed using various hacks (e.g. squatting on space) > > Incredibly unlikely to happen. The ISPs are smart enough to know that > this will cause them more headaches than its worth. You're joking, right? >> - See CGN deployed using a block of space allocated for that purpose > If the IETF rightly denies this request then the ISPs are going to be > forced to use the proper option, 1918 space. No. ISPs will do what makes business sense for them. Some of these ISPs have already indicated that RFC 1918 won't work for them. As such, they'll take whatever steps they feel is in their best interests. Whether this is choosing some large block of (currently) unadvertised space or requesting a large block from their RIR (while they still can) is a decision they will make. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call:
Brian E Carpenter wrote: > > On 2012-02-14 05:51, Noel Chiappa wrote: > > > From: Arturo Servin > > > > >> Are you volunteering to buy everyone on earth a new CPE? If not, who > > >> do you suggest will? > > > > > I suggest the ISPs, they are charging for the service, right? > > > > Lots of CPE is actually owned by the customers, not the ISPs. E.g. in our > > house, both our cable modem and the router attached to it are ours. > > Sure, that's very common, but these devices are consumer electronics and > will get gradually replaced by IPv6-supporting boxes as time goes on. > (That is not hand-waving, the generation of boxes with IPv6 support is > starting to appear.) Nobody, I think, is denying that there will be a long > period of coexistence as a result. > > That is a separate question from this draft, which gives ISPs space for > *growing* their IPv4 customer base. I think that is what upsets people. The problem of ISP not newly shipping CPE that is not IPv6 capable needs to be addressed by regulatory power (legistation), rather than by ignorance of the part of the IETF. ISPs *growing* their IPv4 customer base is a natural side effect whenever ISPs allow customers to use equipment that they already have (and might have been using with a different ISP before). The vast majority of customers does not know or care about not having IPv6, because there is _very_ few equipment that is vitally dependent on IPv6, vs. huge amounts of equiment that requires IPv4. If I had a CPE that supported IPv6 (mine is from early 2006 an IPv4-only), my concern would be how to reliably switch IPv6 off, because of the unsolved security and privacy problems that IPv6 brings along. It was the IETFs very own decision to build IPv6 in a fashion that it is not transparently backwards compatible with IPv4. If the is anyone to blame for the current situation, than it is the IETF, not the consumers or the ISPs (except for those folks at ISPs who participated in the development of IPv6). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/13/2012 12:45, David Conrad wrote: > On Feb 13, 2012, at 12:34 PM, Doug Barton wrote: >>> If an ISP can't use a shared block, they'll go ask their RIR for >>> a block - and given that they demonstrably have the need (lots of >>> customers), they will get it. Multiply than by N providers. >> >> If the RIRs do not deny these requests there is likely to be a >> revolt. OTOH that may be a good thing > > What grounds would an RIR have to deny this request? I haven't kept up to date on all of the RIRs' policies for granting requests, but I don't recall seeing "give me a huge block so that I can do CGN" as one of the established criteria. >>> - See CGN deployed using various hacks (e.g. squatting on space) >> >> Incredibly unlikely to happen. The ISPs are smart enough to know >> that this will cause them more headaches than its worth. > > You're joking, right? Ok, let's assume I'm wrong. Then there are 2 options: 1. They squat on space that causes them (and their customers) pain. I'm fine with that. Hopefully it will encourage their customers to move away, thus causing more pain for the ISP. 2. They squat on space that doesn't cause pain. I don't like that option, but it solves the problem, right? >>> - See CGN deployed using a block of space allocated for that >>> purpose >> If the IETF rightly denies this request then the ISPs are going to >> be forced to use the proper option, 1918 space. > > No. ISPs will do what makes business sense for them. Some of these > ISPs have already indicated that RFC 1918 won't work for them. I've already covered all the reasons I don't buy this in detail. Doug -- It's always a long day; 86400 doesn't fit into a short. 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: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Mon, Feb 13, 2012 at 9:34 PM, Doug Barton wrote: > On 02/12/2012 13:34, Noel Chiappa wrote: >> > From: Nilsson >> >> > there _is_ a cost, the cost of not being able to allocate unique >> > address space when there is a more legitimate need than the proposed >> > wasting of an entire /10 to please those who did not do the right >> > thing. >> >> On the contrary, denying this block is likely to _accelerate_ usage of >> what space remains, thereby penalizing the 'other users' whose interests >> you _claim_ to be protecting. >> >> If an ISP can't use a shared block, they'll go ask their RIR for a block - >> and given that they demonstrably have the need (lots of customers), they >> will get it. Multiply than by N providers. > > If the RIRs do not deny these requests there is likely to be a revolt. > OTOH that may be a good thing > > As for your other 2 options: > >> But it is. As I said before, the IETF has precisely two choices: >> >> - See CGN deployed using various hacks (e.g. squatting on space) > > Incredibly unlikely to happen. The ISPs are smart enough to know that > this will cause them more headaches than its worth. > >> - See CGN deployed using a block of space allocated for that purpose > > If the IETF rightly denies this request then the ISPs are going to be > forced to use the proper option, 1918 space. Whatever customer support > costs they have to bear for the small percentage of customers that > actually manage to overlap will rightly be borne by the people who > created their own problems. Everyone wins. +1 :-) I did original think it was the lesser evil to support this draft, but I have now changed my mind. Plenty of arguments from so many on so many points that I can't really see any reason anymore to support it. So, no I don't support this draft. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
> From: Doug Barton > I haven't kept up to date on all of the RIRs' policies for granting > requests, but I don't recall seeing "give me a huge block so that I > can do CGN" as one of the established criteria. An ISP needs a block of size X for CGN only if it has X customers, right? So they can legitimately go to an RIR and say "I have X customers, please give me a block of size X". The fact that the block is not then advertized globally, but only used to number their CGN'd network, is neither here nor there. Needless to say, if multiple ISPs do this, it will use _more_ address space than simply giving them all a CGN block to share. (Unless that's the _actual_ goal in opposing this, of course.) > I've already covered all the reasons I don't buy this in detail. I can repeat "2+2=5" as many times as I like, but that won't make it true. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call:
Martin Rex wrote: > The problem of ISP not newly shipping CPE that is not IPv6 capable > needs to be addressed by regulatory power (legistation), That's how OSI failed. > rather than by ignorance of the part of the IETF. So will be IPv6 by IETF as a regulatory power to prohibit address space allocation. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery
Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. This request was received Feb. 2, 2012. This document describes an extension to DHCPv4 for the bulk query and transfer of current lease status over TCP. The following transport issues were noted, and are significant: UPDATES- The document updates DHCP with support for TCP, and as such this document seems like it should UPDATE RFC2131 PORT USE- Although DHCPv4 has an assigned TCP port, this document should clearly indicate that there is no other specified use of that port other than the bulk lease query described in this document It should further explain why no other existing DHCP exchanges are not valid on the TCP port. CONNECTION MANAGEMENT- The document describes the use of TCP connections for bulk transfer, but needs to be more specific about which side (relay client or server) closes the connection, under what circumstances, and with what mechanism (e.g., graceful CLOSE vs. ABORT, as per RFC 793) sec 7.3 indicates some conditions for terminating connections; this section should indicate which side performs this, and by what method (CLOSE, ABORT) this sec also allows connections to stay open after all pending transactions are complete (MAY); the rationale for this should be given, or the connection MUST be closed. the same issue applies to sec 7.8 and 8 throughout; sec 8.5 is particularly problematic on this issue because it discusses aborting a request using in-band data, which may not be available if the connection is closed using ABORT. the state of other pending connection shsould be discussed too. TIMEOUTS- Sec 6.3 defines a timeout for the TCP connection; is this intended to supercede any TCP timeout? or is it intended to be the min of the TCP timeout and the specified one? This section should more carefully explain behavior when a connection is dropped and the reason - e.g., timeout, abort, close. INTERLEAVING- sec 7.7 says that the server MUST interleave replies; there doesn't seem a valid reason for this requirement. clearly the receiver MUST tolerate interleaved replies. having the server interleave replies is relevant only if each request/reply has its own timeout -- which should be overridden if there is another response in progress anyway. This issue should be more clearly explained and motivated. There were some other issues noted in this document. These comments appear below, and although not focused on transport issues, they represent significant issues that IMO should be addressed as well. NOTE - regarding some terminology issues, I did not survey current DHCP RFCs for consistency, but IMO these terms should be corrected even if they are then inconsistent with existing specs. Joe --- Major non-transport issues: - In many places the doc allows inaction to substitute for either positive or negative confirmation. IMO, this invites implementation errors, and should be avoided. E.g., status return codes, data source option missing, query-for-all-configured-IPs, etc. - the data source option reserved codes need more detailed specification. if these are intended for future use, then they MUST be ignored by the receiver (at least). if they are to mean anything at all, at least one bit (typically all of them) MUST be set to zero by the transmitter for implementations that do not support any of the component fields. further, the length of this option MUST be 1 - The protocol supports bulk transfer that is not data driven. This could represent a security vulnerability by exposing information that may not be on the data path (and thus already accessible) to a relay agent. This should be discussed in the security considerations section. - Integer quantities should be referred to as "unsigned 32-bit integers" throughout. - "VPN" is used throughout to refer to "private" addresses (RFC 1918); a VPN is not just private addressing. - (this is a nit with all IDs, FWIW) SHOULD and SHOULD NOT are used throughout without context. Any time SHOULD is used instead of MUST (or SHOULD NOT rather than MUST NOT), it is useful to explain a viable exception. If no such exception exists, the rationale for selecting SHOULD over MUST should be included. - It would be useful to explain why STATUS-CODE strings MUST NOT be null-terminated; is that a protocol violation, or are you just saying that NULLs are valid in these strings? the description should be clear that the string field describes the string length without any termination characte
Re: Last Call:
In message <201202132046.q1dkk1hn020...@fs4113.wdf.sap.corp>, Martin Rex writes : > Brian E Carpenter wrote: > > > > On 2012-02-14 05:51, Noel Chiappa wrote: > > > > From: Arturo Servin > > > > > > >> Are you volunteering to buy everyone on earth a new CPE? If not, w > ho > > > >> do you suggest will? > > > > > > > I suggest the ISPs, they are charging for the service, right? > > > > > > Lots of CPE is actually owned by the customers, not the ISPs. E.g. in our > > > house, both our cable modem and the router attached to it are ours. > > > > Sure, that's very common, but these devices are consumer electronics and > > will get gradually replaced by IPv6-supporting boxes as time goes on. > > (That is not hand-waving, the generation of boxes with IPv6 support is > > starting to appear.) Nobody, I think, is denying that there will be a long > > period of coexistence as a result. > > > > That is a separate question from this draft, which gives ISPs space for > > *growing* their IPv4 customer base. I think that is what upsets people. > > > The problem of ISP not newly shipping CPE that is not IPv6 capable > needs to be addressed by regulatory power (legistation), rather than > by ignorance of the part of the IETF. > > > ISPs *growing* their IPv4 customer base is a natural side effect > whenever ISPs allow customers to use equipment that they already > have (and might have been using with a different ISP before). You grow your IPv4 customer base by having new customers independent of whether they are IPv6 customers as well. I don't think there is a customer that only wants to connect to IPv6 sites. Having IPv6 doesn't even cut down on needing to supply IPv4 unless you have bleeding edge IPv6 equipment. People still need to connect to IPv4 literals and that will, for a quite a while yet, mean supplying a dual stack service. NAT64 doesn't have a way to inform the CPE on the mapping needed. It would be simple to do with DHCP but know one had written what needs to be in the option. Similarly 464XLAT doesn't provide a way for the CPE to find the prefix. Blindly performing 464XLAT has similar issues to blindly performing 6to4. DS-Lite only became a RFC in the second half of 2011. It will take some time for IPv6 equipment vendors to add support (hosts and routers). > The vast majority of customers does not know or care about not having IPv6, > because there is _very_ few equipment that is vitally dependent on IPv6, > vs. huge amounts of equiment that requires IPv4. If I had a CPE that > supported IPv6 (mine is from early 2006 an IPv4-only), my concern would > be how to reliably switch IPv6 off, because of the unsolved security and > privacy problems that IPv6 brings along. > > > It was the IETFs very own decision to build IPv6 in a fashion that it is > not transparently backwards compatible with IPv4. If the is anyone to > blame for the current situation, than it is the IETF, not the consumers > or the ISPs (except for those folks at ISPs who participated in the > development of IPv6). > > > -Martin > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call:
On Mon, Feb 13, 2012 at 2:06 PM, Mark Andrews wrote: > > In message <201202132046.q1dkk1hn020...@fs4113.wdf.sap.corp>, Martin Rex > writes > : >> Brian E Carpenter wrote: >> > >> > On 2012-02-14 05:51, Noel Chiappa wrote: >> > > > From: Arturo Servin >> > > >> > > >> Are you volunteering to buy everyone on earth a new CPE? If not, w >> ho >> > > >> do you suggest will? >> > > >> > > > I suggest the ISPs, they are charging for the service, right? >> > > >> > > Lots of CPE is actually owned by the customers, not the ISPs. E.g. in our >> > > house, both our cable modem and the router attached to it are ours. >> > >> > Sure, that's very common, but these devices are consumer electronics and >> > will get gradually replaced by IPv6-supporting boxes as time goes on. >> > (That is not hand-waving, the generation of boxes with IPv6 support is >> > starting to appear.) Nobody, I think, is denying that there will be a long >> > period of coexistence as a result. >> > >> > That is a separate question from this draft, which gives ISPs space for >> > *growing* their IPv4 customer base. I think that is what upsets people. >> >> >> The problem of ISP not newly shipping CPE that is not IPv6 capable >> needs to be addressed by regulatory power (legistation), rather than >> by ignorance of the part of the IETF. >> >> >> ISPs *growing* their IPv4 customer base is a natural side effect >> whenever ISPs allow customers to use equipment that they already >> have (and might have been using with a different ISP before). > > You grow your IPv4 customer base by having new customers independent > of whether they are IPv6 customers as well. I don't think there > is a customer that only wants to connect to IPv6 sites. > > Having IPv6 doesn't even cut down on needing to supply IPv4 unless > you have bleeding edge IPv6 equipment. People still need to connect > to IPv4 literals and that will, for a quite a while yet, mean > supplying a dual stack service. > > NAT64 doesn't have a way to inform the CPE on the mapping needed. > It would be simple to do with DHCP but know one had written what > needs to be in the option. > > Similarly 464XLAT doesn't provide a way for the CPE to find the > prefix. Blindly performing 464XLAT has similar issues to blindly > performing 6to4. > 464XLAT may indeed discover the PREF64 using http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-05 Running code says 464XLAT works with IPv4 literals, IPv4 referrals, and IPv4 socket APIs. CB > DS-Lite only became a RFC in the second half of 2011. It will take > some time for IPv6 equipment vendors to add support (hosts and > routers). > >> The vast majority of customers does not know or care about not having IPv6, >> because there is _very_ few equipment that is vitally dependent on IPv6, >> vs. huge amounts of equiment that requires IPv4. If I had a CPE that >> supported IPv6 (mine is from early 2006 an IPv4-only), my concern would >> be how to reliably switch IPv6 off, because of the unsolved security and >> privacy problems that IPv6 brings along. >> >> >> It was the IETFs very own decision to build IPv6 in a fashion that it is >> not transparently backwards compatible with IPv4. If the is anyone to >> blame for the current situation, than it is the IETF, not the consumers >> or the ISPs (except for those folks at ISPs who participated in the >> development of IPv6). >> >> >> -Martin >> ___ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery
Hi, all, One additional transport suggestion: - it would be useful to include recommended configurations for TCP connections. Given these are multi-byte request/response exchanges, Nagle should be disabled, e.g. Joe On 2/13/2012 2:00 PM, Joe Touch wrote: Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. This request was received Feb. 2, 2012. This document describes an extension to DHCPv4 for the bulk query and transfer of current lease status over TCP. The following transport issues were noted, and are significant: UPDATES- The document updates DHCP with support for TCP, and as such this document seems like it should UPDATE RFC2131 PORT USE- Although DHCPv4 has an assigned TCP port, this document should clearly indicate that there is no other specified use of that port other than the bulk lease query described in this document It should further explain why no other existing DHCP exchanges are not valid on the TCP port. CONNECTION MANAGEMENT- The document describes the use of TCP connections for bulk transfer, but needs to be more specific about which side (relay client or server) closes the connection, under what circumstances, and with what mechanism (e.g., graceful CLOSE vs. ABORT, as per RFC 793) sec 7.3 indicates some conditions for terminating connections; this section should indicate which side performs this, and by what method (CLOSE, ABORT) this sec also allows connections to stay open after all pending transactions are complete (MAY); the rationale for this should be given, or the connection MUST be closed. the same issue applies to sec 7.8 and 8 throughout; sec 8.5 is particularly problematic on this issue because it discusses aborting a request using in-band data, which may not be available if the connection is closed using ABORT. the state of other pending connection shsould be discussed too. TIMEOUTS- Sec 6.3 defines a timeout for the TCP connection; is this intended to supercede any TCP timeout? or is it intended to be the min of the TCP timeout and the specified one? This section should more carefully explain behavior when a connection is dropped and the reason - e.g., timeout, abort, close. INTERLEAVING- sec 7.7 says that the server MUST interleave replies; there doesn't seem a valid reason for this requirement. clearly the receiver MUST tolerate interleaved replies. having the server interleave replies is relevant only if each request/reply has its own timeout -- which should be overridden if there is another response in progress anyway. This issue should be more clearly explained and motivated. There were some other issues noted in this document. These comments appear below, and although not focused on transport issues, they represent significant issues that IMO should be addressed as well. NOTE - regarding some terminology issues, I did not survey current DHCP RFCs for consistency, but IMO these terms should be corrected even if they are then inconsistent with existing specs. Joe --- Major non-transport issues: - In many places the doc allows inaction to substitute for either positive or negative confirmation. IMO, this invites implementation errors, and should be avoided. E.g., status return codes, data source option missing, query-for-all-configured-IPs, etc. - the data source option reserved codes need more detailed specification. if these are intended for future use, then they MUST be ignored by the receiver (at least). if they are to mean anything at all, at least one bit (typically all of them) MUST be set to zero by the transmitter for implementations that do not support any of the component fields. further, the length of this option MUST be 1 - The protocol supports bulk transfer that is not data driven. This could represent a security vulnerability by exposing information that may not be on the data path (and thus already accessible) to a relay agent. This should be discussed in the security considerations section. - Integer quantities should be referred to as "unsigned 32-bit integers" throughout. - "VPN" is used throughout to refer to "private" addresses (RFC 1918); a VPN is not just private addressing. - (this is a nit with all IDs, FWIW) SHOULD and SHOULD NOT are used throughout without context. Any time SHOULD is used instead of MUST (or SHOULD NOT rather than MUST NOT), it is useful to explain a viable exception. If no such exception exists, the rationale for selecting SHOULD over MUST should be included. - It would be useful to explain why STATUS-CODE strings MUST NOT be null-terminated; is that a protocol
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Mon, Feb 13, 2012 at 03:42:58PM -0500, Noel Chiappa wrote: > > From: Doug Barton > > > If the RIRs do not deny these requests there is likely to be a revolt. > > On what grounds? The ISPs will come along and say 'I have X new customers, > please give me more space for them'. The former being true, on what ground can > the RIRs refuse (modulo cases like RIPE)? RIPE NCC is not unique; IIRC there has been extensive synchronisation between RIRen on the subject of sunset allocations. I'd expect any RIR to more or less laugh at the request of a /10 (the size of network we've been told (without any proof beyond handwaving) is required to do CGN nicely) at this stage of address depletion. APNIC: As of Friday, 15 April 2011, each new or existing APNIC account holder is only eligible to request and receive delegations totalling a maximum /22 worth of address space from the APNIC IPv4 address pool. ARIN: Has 3-month consumption cap on allocations. Apparently not so low on space as the others. LACNIC: Has a /22 cap per LIR en route in its PDP. RIPE: Has a /22 rule, as discussed earlier. AFRINIC: I can't at the moment locate their policy, more than that they have incorporated the "last five /8's" document as governing text in their policy set. Pointers to text welcome. To sum things up, we are at the stage where a /10 is a laughable proposition. The largest usable block (bar squatting on DOD space) for CGN is 10/8. I'd suggest planning for it. That last /22 will probably end up as P router addresses in MPLS core, since all vendors have dragged their feet in implementing v6 MPLS. > > If the IETF rightly denies this request then the ISPs are going to > > be forced to use the proper option, 1918 space. > > How? The IETF has neither police, nor an army. It is either 10/8 or squat. No other alternatives exist. I'd expect squatting on the "wrong" /8 to be punishable as a Homeland Security Department -related crime, if one takes the US-centric view. Folks, we've run out. -- Måns. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Hi Noel, At 12:42 13-02-2012, Noel Chiappa wrote: On what grounds? The ISPs will come along and say 'I have X new customers, please give me more space for them'. The former being true, on what ground can the RIRs refuse (modulo cases like RIPE)? If you have X new customers and you ask a RIR to give you more IPv4 space, I doubt that you would get more space as the evaluation might require more information ( e.g. http://www.ripe.net/lir-services/resource-management/contact/ipv4-evaluation-procedures ). Here's a comparison of RIR policies. Please refer to the document from each RIR for authoritative information. RIR Period (months) AfriNIC12 Minimum /22, no maximum Demonstrate 80% efficient utilization of last allocated space or an immediate need that requires more IP addresses than are available in the most recent allocation. APNIC 12 Minimum /24, up to a maximum /22 of the remaining available space after 15 April 2011. Demonstrate 80% efficient utilization of all prior allocated space. ARIN3 Minimum /22 for multihomed, otherwise /20, no maximum. Demonstrate efficient utilization of all previous allocations and at least 80% of the most recent allocation. LACNIC 12 The policy for determining the size of additional allocations is based on the efficient utilization of space within a time frame of 12 months. Demonstrate 80% efficient utilization of all prior allocated space. The applicant must already have at least one IPv6 block assigned by LACNIC or, if not, must simultaneously request an initial IPv6 block in accordance with the corresponding applicable policy. If an applicant has already been assigned an IPv6 block, they shall submit to LACNIC a brief document describing their progress in the implementation of IPv6. RIPE Minimum /21, no maximum. Demonstrate approximately 80% efficient utilization of all prior allocated space. Until 1 July 2010, up to 12 months. Between 1 July 2010 31 December 2010, up to nine months Between 1 January 2011- 31 June 2011, up to six months As of 1 July 2011, up to three months According to the above, you can still get an allocation of IPv4 addresses. The amount depends on the regional policy. Whether a /10 allocation is possible from the above is an exercise left to the reader. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/13/2012 13:46, Noel Chiappa wrote: > > From: Doug Barton > > > I haven't kept up to date on all of the RIRs' policies for granting > > requests, but I don't recall seeing "give me a huge block so that I > > can do CGN" as one of the established criteria. > > An ISP needs a block of size X for CGN only if it has X customers, right? So > they can legitimately go to an RIR and say "I have X customers, please give me > a block of size X". The fact that the block is not then advertized globally, > but only used to number their CGN'd network, is neither here nor there. If they have a legitimate need for "more customers -> more space" I have no problem with that. If they lie on their application about what they are using it for ... > Needless to say, if multiple ISPs do this, it will use _more_ address space > than simply giving them all a CGN block to share. (Unless that's the _actual_ > goal in opposing this, of course.) Um, no. I'm not trying to accelerate IPv4 runout. I get that it's an important problem, and I've been working on solutions for it for many years. But that doesn't mean I buy the arguments that have been put forward so far about why this new block is "necessary" either. > > I've already covered all the reasons I don't buy this in detail. > > I can repeat "2+2=5" as many times as I like, but that won't make it true. 2+2!=5 is a fact. What you and I are talking about are opinions. I happen to think that my opinions are better grounded in facts and knowledge about the topic than yours are, but at the end of the day we could both be wrong about what actually does or doesn't happen. Doug -- It's always a long day; 86400 doesn't fit into a short. 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: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Mans, On Feb 13, 2012, at 2:17 PM, Måns Nilsson wrote: > To sum things up, we are at the stage where a /10 is a laughable > proposition. Other than APNIC, I don't think this is correct. Perhaps folks from the RIRs can confirm. > It is either 10/8 or squat. No other alternatives exist. I'd expect > squatting on the "wrong" /8 to be punishable as a Homeland Security > Department -related crime, if one takes the US-centric view. I doubt this, particularly since the use of the addresses we're talking about is entirely internal. > Folks, we've run out. "I'm not dead yet!" (to misquote Monty Python) Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Mon, Feb 13, 2012 at 02:36:34PM -0800, David Conrad wrote: > Mans, > > On Feb 13, 2012, at 2:17 PM, Måns Nilsson wrote: > > To sum things up, we are at the stage where a /10 is a laughable > > > proposition. > > Other than APNIC, I don't think this is correct. Perhaps folks from the RIRs > can confirm. Reading from policy texts, it is. What is stuffed away in the RIR dungeons might technically support such an allocation, of course. For some time still. > > It is either 10/8 or squat. No other alternatives exist. I'd expect > > squatting on the "wrong" /8 to be punishable as a Homeland Security > > Department -related crime, if one takes the US-centric view. > > I doubt this, particularly since the use of the addresses we're talking about > is entirely internal. Internal schmernal. Stuff leaks. Either by people watching allocations and going "Hey" or by routing slip "Hey, this block ain't 1918, let's route it...". > > Folks, we've run out. > > "I'm not dead yet!" (to misquote Monty Python) The rumours are persistent, though. -- Måns. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call:
In message
, Cameron Byrne writes:
> On Mon, Feb 13, 2012 at 2:06 PM, Mark Andrews wrote:
> >
> > In message <201202132046.q1dkk1hn020...@fs4113.wdf.sap.corp>, Martin Rex =
> writes
> > :
> >> Brian E Carpenter wrote:
> >> >
> >> > On 2012-02-14 05:51, Noel Chiappa wrote:
> >> > > =A0 =A0 > From: Arturo Servin
> >> > >
> >> > > =A0 =A0 >> Are you volunteering to buy everyone on earth a new CPE? =
> If not, w
> >> ho
> >> > > =A0 =A0 >> do you suggest will?
> >> > >
> >> > > =A0 =A0 > I suggest the ISPs, they are charging for the service, rig=
> ht?
> >> > >
> >> > > Lots of CPE is actually owned by the customers, not the ISPs. E.g. i=
> n our
> >> > > house, both our cable modem and the router attached to it are ours.
> >> >
> >> > Sure, that's very common, but these devices are consumer electronics a=
> nd
> >> > will get gradually replaced by IPv6-supporting boxes as time goes on.
> >> > (That is not hand-waving, the generation of boxes with IPv6 support is
> >> > starting to appear.) Nobody, I think, is denying that there will be a =
> long
> >> > period of coexistence as a result.
> >> >
> >> > That is a separate question from this draft, which gives ISPs space fo=
> r
> >> > *growing* their IPv4 customer base. I think that is what upsets people=
> .
> >>
> >>
> >> The problem of ISP not newly shipping CPE that is not IPv6 capable
> >> needs to be addressed by regulatory power (legistation), rather than
> >> by ignorance of the part of the IETF.
> >>
> >>
> >> ISPs *growing* their IPv4 customer base is a natural side effect
> >> whenever ISPs allow customers to use equipment that they already
> >> have (and might have been using with a different ISP before).
> >
> > You grow your IPv4 customer base by having new customers independent
> > of whether they are IPv6 customers as well. =A0I don't think there
> > is a customer that only wants to connect to IPv6 sites.
> >
> > Having IPv6 doesn't even cut down on needing to supply IPv4 unless
> > you have bleeding edge IPv6 equipment. =A0People still need to connect
> > to IPv4 literals and that will, for a quite a while yet, mean
> > supplying a dual stack service.
> >
> > NAT64 doesn't have a way to inform the CPE on the mapping needed.
> > It would be simple to do with DHCP but know one had written what
> > needs to be in the option.
> >
> > Similarly 464XLAT doesn't provide a way for the CPE to find the
> > prefix. =A0Blindly performing 464XLAT has similar issues to blindly
> > performing 6to4.
> >
>
> 464XLAT may indeed discover the PREF64 using
> http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-05
draft-ietf-behave-nat64-discovery-heuristic-05 really isn't a solution.
It doesn't say anything about choosing the A records such that there
is no abmiguity when look for the embedded address.
It doesn't have the exceptions which are part of DNS64. This means
you can't use it reliably with dual stack internal and IPv6-only
external.
Below is the DNS64 configuration elements from named.
dns64 {
break-dnssec ;
clients { ; ... };
exclude { ; ... };
mapped { ; ... };
recursive-only ;
suffix ;
};
While not all of them are required for IPv4 literals more than netprefix and
suffix are required which is all draft-ietf-behave-nat64-discovery-heuristic-05
delivers.
> Running code says 464XLAT works with IPv4 literals, IPv4 referrals,
> and IPv4 socket APIs.
> CB
>
> > DS-Lite only became a RFC in the second half of 2011. =A0It will take
> > some time for IPv6 equipment vendors to add support (hosts and
> > routers).
> >
> >> The vast majority of customers does not know or care about not having IP=
> v6,
> >> because there is _very_ few equipment that is vitally dependent on IPv6,
> >> vs. huge amounts of equiment that requires IPv4. =A0If I had a CPE that
> >> supported IPv6 (mine is from early 2006 an IPv4-only), my concern would
> >> be how to reliably switch IPv6 off, because of the unsolved security and
> >> privacy problems that IPv6 brings along.
> >>
> >>
> >> It was the IETFs very own decision to build IPv6 in a fashion that it is
> >> not transparently backwards compatible with IPv4. =A0If the is anyone to
> >> blame for the current situation, than it is the IETF, not the consumers
> >> or the ISPs (except for those folks at ISPs who participated in the
> >> development of IPv6).
> >>
> >>
> >> -Martin
> >> ___
> >> Ietf mailing list
> >> Ietf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ietf
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is=
> c.org
> > ___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.o
Backwards compatibility myth [Re: Last Call: ]
Martin Rex wrote: ... >> It was the IETFs very own decision to build IPv6 in a fashion that it is >> not transparently backwards compatible with IPv4. If the is anyone to >> blame for the current situation, than it is the IETF, not the consumers >> or the ISPs (except for those folks at ISPs who participated in the >> development of IPv6). People say this from time to time, but it's a complete myth. IPv4 provides no mechanism whatever for addresses greater than 32 bits. Therefore, mathematically, there is no possible design for an IP with bigger addresses that is transparently backwards compatible. We've known that since at least 1992. The design error was made in the late 1970s, when Louis Pouzin's advice that catenet addresses should be variable length, with a format prefix, was not taken during the design of IPv4. (There were advocates of variable length addresses for IPng, but the 128 bit choice won on the grounds that it is enough for anything, which 32 bits clearly wasn't.) Brian (donning flameproof clothing) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: ]
On 2/13/2012 4:17 PM, Brian E Carpenter wrote: People say this from time to time, but it's a complete myth. well, not completely... IPv4 provides no mechanism whatever for addresses greater than 32 bits. Therefore, mathematically, there is no possible design for an IP with bigger addresses that is transparently backwards compatible. We've known that since at least 1992. The path that the IETF followed ensured the maximum amount of incompatibility. Really a completely independent stack. In contrast, the IETF could easily have chose a path toward minimizing incompatibility that would have allowed IPv6 to interwork with IPv4, within the limitations of the v4 address space. That is, the IETF could begun IPv6 by assigning to it IPv4 addresses, reserving the remainder for latter definition and allocation. It could have targeted simple, basic reformatting at the IP level to permit early IPv6 adoption to require a minimal gateway for interworking with the IPv4 world. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: ]
On 2012-02-14 13:32, Dave CROCKER wrote: > > > On 2/13/2012 4:17 PM, Brian E Carpenter wrote: >> People say this from time to time, but it's a complete myth. > > well, not completely... > > >> IPv4 provides no mechanism whatever for addresses greater than 32 bits. >> Therefore, mathematically, there is no possible design for an IP with >> bigger addresses that is transparently backwards compatible. We've known >> that since at least 1992. > > > The path that the IETF followed ensured the maximum amount of > incompatibility. Really a completely independent stack. > > In contrast, the IETF could easily have chose a path toward minimizing > incompatibility that would have allowed IPv6 to interwork with IPv4, > within the limitations of the v4 address space. > > That is, the IETF could begun IPv6 by assigning to it IPv4 addresses, > reserving the remainder for latter definition and allocation. It could > have targeted simple, basic reformatting at the IP level to permit early > IPv6 adoption to require a minimal gateway for interworking with the > IPv4 world. There were very specific reasons why this was not done. And it doesn't change the fact that an old-IP-only host cannot talk to a new-IP-only host without a translator. It is that fact that causes our difficulties today. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: ]
On 2/13/2012 4:38 PM, Brian E Carpenter wrote: There were very specific reasons why this was not done. Is there a useful citation that covers this strategic decision? Given that that decision was an essential part of what caused a roughly 15 year delay, it would be helpful to have it documented. And it doesn't change the fact that an old-IP-only host cannot talk to a new-IP-only host without a translator. It is that fact that causes our difficulties today. The translator needed today is a complete gateway between two entirely incompatible protocols. The one that I'm describing would have been a trivial re-formatter. The development, deployment and interoperability differences between these is massive. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: ]
> IPv4 provides no mechanism whatever for addresses greater than 32 bits. > Therefore, mathematically, there is no possible design for an IP with > bigger addresses that is transparently backwards compatible. We've known > that since at least 1992. i guess you forget the discussion of variable length. i hope we don't have to rehash it here. decisions were made. some were quite bad. v6 had some real zingers. remember tla/nla? no feature parity, such as dhcp (a war which has not finished)? it is almost as if it was designed to fail. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: ]
On 2012-02-14 13:42, Dave CROCKER wrote: > > > On 2/13/2012 4:38 PM, Brian E Carpenter wrote: >> There were very specific reasons why this was not done. > > Is there a useful citation that covers this strategic decision? You may recall that at the time, we were very concerned about the pre-CIDR growth rate in BGP and there was, iirc, a generalised aversion to anything that would import the entire IPv4 BGP4 table into IPv6. I don't recall without a lot of archive grepping whether this was explicit in the IPng decision or whether it came a bit later. > > Given that that decision was an essential part of what caused a roughly > 15 year delay, it would be helpful to have it documented. > > >> And it doesn't >> change the fact that an old-IP-only host cannot talk to a new-IP-only >> host >> without a translator. It is that fact that causes our difficulties today. > > The translator needed today is a complete gateway between two entirely > incompatible protocols. The one that I'm describing would have been a > trivial re-formatter. > > The development, deployment and interoperability differences between > these is massive. Honestly, having had an MSc student who benchmarked translation vs application proxying vs native, I don't think so. The mechanics of packet translation are trivial. The hard part is exactly the same as with NAT44, caused by the shortage of IPv4 addresses and all the state that goes with sharing the pool of transport ports for a single address. On 2012-02-14 13:49, Randy Bush wrote: > i guess you forget the discussion of variable length. i hope we don't > have to rehash it here. I haven't forgotten. The worst row I ever had at an IETF meeting was on that topic. > decisions were made. some were quite bad. v6 had some real zingers. > remember tla/nla? no feature parity, such as dhcp (a war which has not > finished)? it is almost as if it was designed to fail. DHCP for v4 was still wet behind the ears at that time, so this wasn't as obvious then as it is now; there's a bit of 20/20 hindsight here. But yes, we could of course have done better. Unfortunately my time machine is broken. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call:
Brian E Carpenter wrote: > >Dave CROCKER wrote: >> >> Brian E Carpenter wrote: >>> >>> There were very specific reasons why this was not done. >> >> Is there a useful citation that covers this strategic decision? > >You may recall that at the time, we were very concerned about the >pre-CIDR growth rate in BGP and there was, iirc, a generalised >aversion to anything that would import the entire IPv4 BGP4 table >into IPv6. I don't recall without a lot of archive grepping whether >this was explicit in the IPng decision or whether it came a bit later. With the result that you have two independent routing tables describing the entire internet instead of just one. I do not see a size benefit, only the possibility for seperate code so that during development of IPv6, the old IPv4 code that carries the larger part of the Internet traffic is subject to less changes and therefore less new bugs. > > > > > Given that that decision was an essential part of what caused a roughly > > 15 year delay, it would be helpful to have it documented. > > > > > >> And it doesn't > >> change the fact that an old-IP-only host cannot talk to a new-IP-only > >> host > >> without a translator. It is that fact that causes our difficulties today. > > > > The translator needed today is a complete gateway between two entirely > > incompatible protocols. The one that I'm describing would have been a > > trivial re-formatter. > > > > The development, deployment and interoperability differences between > > these is massive. > > Honestly, having had an MSc student who benchmarked translation vs > application proxying vs native, I don't think so. The mechanics of > packet translation are trivial. The hard part is exactly the same as > with NAT44, caused by the shortage of IPv4 addresses and all the state > that goes with sharing the pool of transport ports for a single address. the difference in connection setup seems to huge, that folks came up with the happy eyeballs proposal -- at an enormous cost of change for apps that aren't multi-threaded or async multi-connect yet, and extra load for the network and Server OS. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: ]
> From: Brian E Carpenter > The design error was made in the late 1970s, when Louis Pouzin's advice > that catenet addresses should be variable length, with a format prefix, > was not taken during the design of IPv4. Ironically, TCP/IP had variable length addresses put in _twice_, and they were removed both times! (You can't make this stuff up! :-) - TCPv1 (no separate TCP and IP at that point) had variable lenth addresses of up to 15 4-bit nibbles - TCP/IPv3 had variable lenth addresses of up to 15 8-bit bytes (but the 'network number' part was supposed to be only the first byte, exactly like IPv4 in its early days) This latter change happened shortly before I joined the project, otherwise no doubt I would have strenously objected! :-) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: ]
Brian E Carpenter wrote: > There were very specific reasons why this was not done. And it doesn't > change the fact that an old-IP-only host cannot talk to a new-IP-only host > without a translator. It is that fact that causes our difficulties today. The fact is that an old-IP-only host can talk to a new-IP-only host without a translator, if the new IP uses port numbers for addressing/routing. Though NAT is doing similar thing with translation, the translation is not essential and can be reversed at end systems using NAT information obtained through UPnP/PCP. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Brian E Carpenter wrote: > Sure, that's very common, but these devices are consumer electronics and > will get gradually replaced by IPv6-supporting boxes as time goes on. The problem is that IPv6 specification is still broken in several ways to be not operational that existing boxes must be replaced after the specification is fixed. The more serious problem is that IPv6 people in IETF do not admit IPv6 broken, which makes it impossible to fix IPv6. For an example, see my recent presentation at APOPS: http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
