Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Sorry Noel but I choice to reply public to this one. On Mon, Feb 13, 2012 at 10:52 PM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: IPv6 is The Key! If you think denying a CGN block will do anything at all to help IPv6, you're very confused. quote out of context etc... but my change of mind from supporting this draft to not supporting has nothing todo with IPv6 at all. Nothing. It all boils down to RFC1918 space, there are 3 huge network blocks there and double, tripple NAT work, just as well as CGN will (it will break plenty of application either way). * 10.0.0.0/8 ~16mill addresses * 172.16.0.0/12 ~1mill addresses * 192.168.0.0/16 ~65K addresses I can't really see what difference another /10 will make really, especially now that we're in essence out of IPv4 addresses. We're all much better of with some pain (address collision etc) during the transition to IPv6 than to delay it even more. And about your quote, yes we have to change to IPv6, there are at currently no other options at all. Sure there are plenty of not optimal design choice made, stupid things (like we're wasting /64 due to EUI-64) etc etc, but that is an entire other range of subject. Right now, we only have one real choice, move to IPv6. Everything else is moving the pain around. and for those that really really really want to continue to use IPv4, well try to make 240/4 (E-class) usable... there you have an entire /4 instead of /10. 240.0.0.0/4 Reserved for Future Use[RFC1700, page 4] I personally think that reservation should have been lifted years ago. -- 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: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Tue, Feb 14, 2012 at 5:51 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: 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. Make a draft, gather your supporters and take that discussion on 6man wg. I'm sure there are people open to consider any arguments on what's wrong/or not. Either way, we're way passed changing any of the important parts of IPv6. That has to be IPv6 v2 WITH backward compability to IPv6 (as we currently know it). -- 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: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
The more serious problem is that IPv6 people in IETF do not admit IPv6 broken, which makes it impossible to fix IPv6. Make a draft, gather your supporters and take that discussion on 6man wg. I'm sure there are people open to consider any arguments on what's wrong/or not. Now, I'm tired of speaking with those who decided that IPv6 must be perfect. They have been warned about 10 years ago. Nowadays, I'm telling operators how IPv6 is broken to be not operational. Either way, we're way passed changing any of the important parts of IPv6. That has to be IPv6 v2 WITH backward compability to IPv6 (as we currently know it). A problem, maybe the worst operationally, of IPv6 is that IPv6 address is 16B, divine to remember, because of failed attempt to have SLAAC. As most operators are human, forget backward compatibility. It is a lot easier for all the players to make IPv4 with NAT end to end transparent. Masataka Ohta ___ 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
Hello Ted and Bell, I tried to address both your comments by combining your proposals: Basically I added the text suggested by Ted in the security considerations section and then I slightly modified the introduction in order to clarify the applicability. I've just posted version -04 that includes these changes together with the resolutions of some other comments we received during the review. Please let me know if you have additional comments. Thanks, Regards, Roberta -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: lunedì 13 febbraio 2012 22.06 To: Ted Lemon Cc: Maglione Roberta; draft-ietf-dhc-forcerenew-nonce@tools.ietf.org; gen-...@ietf.org Review Team; The IETF; Henderickx, Wim (Wim); Ullio Mario Subject: Re: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03 On Feb 11, 2012, at 10:24 AM, Ted Lemon wrote: [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. This is good information, and it would help to include it in the security considerations. I meant (but failed) to comment in my original review that the security considerations would benefit from a more detailed discussion about the properties of the mechanism, and what attacks or vulnerabilities it is intended to mitigate. Your text above seems to do that. [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. Do I infer correctly from your comment that the security properties of the mechanism don't really matter? That is, if the attacker we care about can't eavesdrop in the first place, does this really need to be an HMAC? Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
I support this updated draft, and I am keen for this to be published as a BCP. I believe the amendments in this revision clarify the usage and intended purpose of the shared transition space. Daryl ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]
On 2/13/2012 7:09 PM, Brian E Carpenter wrote: 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. So, an initial requirement that simply said we need a larger address space became we need a larger address space, a new routing architecture, and a slew of other new mechanisms. For an exercise like creating IPv6, this is called second system syndrome.[1] If often accounts for massive delays. 15 years qualifies. 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. In theory, there is no difference between theory and practice... By saying 'benchmarking' you appear to be referring to something like transformation time. But notice that I gave a list that had nothing to do with cpu or i/o performance. I fear that anyone who thinks that developing and operating a slightly enhanced router, such as I described, is the same as an application gateway probably does not understand the relative complexities or OAM demands of either very well. d/ [1][http://en.wikipedia.org/wiki/Second-system_effect -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Roger Jorgensen rog...@gmail.com Sorry Noel but I choice to reply public to this one. Ah, no, actually. Had you thought about it for a moment or two, you could have realized that you could have made your point just as well without publicly quoting my private email. But why am I not surprised? It all boils down to RFC1918 space, there are 3 huge network blocks there ... I can't really see what difference another /10 will make really, especially now that we're in essence out of IPv4 addresses. The issue is not whether it _can_ be made to work (in Milo's famous phrase, 'with enough thrust, anything will fly'). The issue is all about costs and benefits. Speaking of the costs, if we assign a block of size N, it's not as if N people are not going to be able to get on the network as a result. To the contrary, N*M people are going to be able to get on the network as a result. Of course, the N would have had globally visible addresses, whereas the N*M will not, but that dropoff in functionality does not seem to bother most people: pretty much every wireless hub I've ever seen is also a NAT box. (I'm not even sure if there's even a way to turn off the NAT functionality in the one in our house - I don't recall one.) Given that most people are happy to take the choice 'limited access is preferable to no access' in the wireless case, I see no reason to doubt that they would, were they able to explicitly make the choice, make the same choice here. Allowing more people access to the Internet is a problem... how? Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
I also support this draft. Donald On Tuesday, February 14, 2012, Daryl Tanner daryl.tan...@blueyonder.co.uk wrote: I support this updated draft, and I am keen for this to be published as a BCP. I believe the amendments in this revision clarify the usage and intended purpose of the shared transition space. Daryl -- Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
I support this updated draft, and I am keen for this to be published as a BCP. +1 I believe the amendments in this revision clarify the usage and intended purpose of the shared transition space. +1 Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
I support this draft as updated. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt
+1. One point I would like to make regarding not being encourage to move to IPv6, was increased when the RIRs established the new IPv4 request prove your need policies. It immediately strengthen the notion that we must keep our existing IPv4 Class C network because if we let it go, we might not be able to get it back. If this policy was in place, when we first migrated to the net in the 90s', I could easily see a problem of being denied or hassled enough to show why our then new business plan should be enough. IOW, the RIR policies only strengthen existing companies to be very careful about migrating to IPv6, which in itself is inherently complex and still long time. IPv4 is still required for reachability during any migration period which seems to me will be a very very long time. Of course, a HDTV industry lobby can force federal legislation to force the migration and new equipment to be IPv6 ready. But TVs is a consumer market mostly. With IP, its commercial interest as well, and there will be resistance if there is a major cost involved to make the change - or at least some federal subsidy will be demanded if its going to be forced. Ma Bell did it right when they changed from 7 digit local calls to requiring the 10 digits today for new local area codes. And this was before customers were legally allowed to own their phone numbers for life, make it transferable. I'm sure the ideal forward thinker at Ma Bell would of said, If we are changing it number to 10, why not get ready and make it 16 or 20? I think that would be been harder to do to make that change. 10 was good because it was already part of the people's mindset to make the non-local call. Not the same analogy of course, its possible to add more digits to reach any end-phone. Not possible with IPv4 unless a port is used which is the only possible extension to it. Anyway, I agree with your points regarding the realities. IPv6 is a costly endeavor, IPv4 with NATs is what people are using at all levels, consumers and business, simply because of cost and it allows people to continue to operate at all levels. -- HLS Martin Rex wrote: Brian E Carpenter wrote: On 2012-02-14 05:51, Noel Chiappa wrote: From: Arturo Servin arturo.ser...@gmail.com 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another last call for draft-weil
I support draft-weil as revised. There is a vital need for this to move forward and the IETF should stop standing in the way and let ARIN allocate the space already. Owen On Feb 13, 2012, at 10:09 AM, Chris Grundemann wrote: Fellow BDGKS Authors, FYI: draft-weil is in another Last Call following an update that was requested by IESG Ads (on their December telechat, some ADs asked us to turn our request into a request for more 1918 space, but with a few caveats to home router manufacturers about not breaking when exposed to a CGN environment.). At this point we don't expect to change any minds. Basically everyone who is against the draft has spoken up. Now it is just a numbers game, we need to demonstrate significant support for the draft. If you do support this I-D and the allocation of the /10 for shared CGN use, please consider posting a statement of support. Something as simple as I support this draft as updated or I think the updated draft is more flexible, and would satisfy additional use cases that don't work with RFC1918 space would be very helpful. You can respond to the Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP thread or post individually to ietf@ietf.org. Also, please feel free to encourage anyone else you know who supports the draft to make a similar post. Every statement we can gather is vital right now. Last call ends on Thursday, so reply's must be made before then. Thank you. Cheers, ~Chris ___ 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
Hi, thanks for the response. See additional comments inline. (I removed sections for which no further comment seems necessary) On Feb 10, 2012, at 7:52 AM, Maglione Roberta wrote: [...] -- I admit to not being a DHCP expert, but If I understand this draft correctly, it proposes to send what is effectively a secret-key in a DHCPACK request, then use that key to authenticate a force renew message. It seems like any eavesdropper could sniff that key, and use it to spoof force renew requests. The introduction mentions that there may be some environments where the use of RFC3118 authentication could be relaxed, and offers an example of such an environment. But nowhere does this draft appear to be limited in scope to such environments. [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. That helps, although I would suggest an additional sentence mentioning the specific risk in using it in environments without sufficient protection. I note, however, that Ted objected to this in a separate email--I will reply there as well. I think some additional text in (perhaps in the security considerations) is needed to explain either why the vulnerability to eavesdroppers is either okay in general, or limits the mechanism's use to environment where it is okay. It also seems like that, in the best case, this mechanism proves only that a Forcerenew request comes from the same DHCP server as in the original transaction, but otherwise does not prove anything about the identity of that server. If so, it would be worth mentioning it. [RM] That's correct this mechanism only proves only that a Forcerenew request comes from the same DHCP server: let me say this is a trade off between the total security provided by RFC 3118 and no security at all. In addition this method relays on the same mechanism already used for DHCPv6 Reconfigure message Understood, and your suggested text from the previous comment mitigates this a bit. It would help to include text describing exactly what security properties you expect from the mechanism. (e.g. Proving (with limitations) that Forcerenew requests come from the same server as the original transaction response, etc.) -- The mechanism appears to be limited to HMAC-MD5, and there does not appear to be any way of selecting other algorithms. Is HMAC-MD5 really sufficient as the only choice? Is there some expectation that stronger mechanisms or algorithm extensibility would be too expensive? (Perhaps the extensibility method would be to specify another mechanism that's identical except for a different HMAC algorithm. But if that's the intent it should be mentioned.) [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. RFC 3315 was published in 2003. I'm not sure the general impression of HMACMD5 is the same now as it was in 2003. For example, http://www.ietf.org/mail-archive/web/cfrg/current/msg01197.html . I'm willing to accept that HMACMD5 is perfectly okay for this application, but it would be good to document more motivation than the fact it was used in 3315. If 3315 was being written today, would they use it? Is matching 3315 an important goal? I'm more interested in whether HMACMD5 is adequate for this particular use case based on today's knowledge about possible vulnerabilities or operational issues. [I mentioned in my original review that I think this draft should get a SecDir review. They could certainly access whether hmacmd5 is an issue better than I can.] *** Minor issues: [...] -- section 3.1.3, 2nd paragraph: The server SHOULD NOT include this option unless the client has indicated its capability in a DHCP Discovery message. Why not; what harm would it do? And on the other hand, if you want to discourage it, why not go all the way to MUST NOT? [RM] For backward compatibility: if the client did not indicate its capability for this feature it means it is a legacy client and it does not support it, so the server should not send the nonce to this client The text is not talking about sending the nonce--it's talking about sending the FORCERENEW_NONCE_CAPABLE option. Unless I read it wrong, it is saying the server SHOULD not advertise support unless the client has already indicated support. -- section 3.1.3, 5th paragraph: ... computes an HMAC-MD5 of the Forcerenew message using the Forcerenew nonce . Using it how? Is it the secret key for the HMAC calculation?
Re: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03
On Feb 11, 2012, at 10:24 AM, Ted Lemon wrote: [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. This is good information, and it would help to include it in the security considerations. I meant (but failed) to comment in my original review that the security considerations would benefit from a more detailed discussion about the properties of the mechanism, and what attacks or vulnerabilities it is intended to mitigate. Your text above seems to do that. [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. Do I infer correctly from your comment that the security properties of the mechanism don't really matter? That is, if the attacker we care about can't eavesdrop in the first place, does this really need to be an HMAC? ___ 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
On Feb 13, 2012, at 4:06 PM, Ben Campbell wrote: Do I infer correctly from your comment that the security properties of the mechanism don't really matter? That is, if the attacker we care about can't eavesdrop in the first place, does this really need to be an HMAC? Hm, I thought about that a bit more after I wrote my response. The HMAC allows us to avoid sending the nonce in the clear in the DHCPFORCERENEW. I don't think this adds any value from a security perspective, actually, even though it feels more comfortable. I suspect it was put in in the original version simply because of that—why send a secret over the wire when you don't have to? However, the original motivation for using the mechanism from RFC3315 was to avoid defining a new mechanism for a legacy protocol. If we do need to change it, it's going to require a major rework of the document, and a lot of delay, so if it causes no harm, I think that's not worth doing. I too would like to see the text I proposed added to the security considerations, so that we can be clear about what is being accomplished with this draft. ___ 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
On Feb 13, 2012, at 3:21 PM, Ted Lemon wrote: On Feb 13, 2012, at 4:06 PM, Ben Campbell wrote: Do I infer correctly from your comment that the security properties of the mechanism don't really matter? That is, if the attacker we care about can't eavesdrop in the first place, does this really need to be an HMAC? Hm, I thought about that a bit more after I wrote my response. The HMAC allows us to avoid sending the nonce in the clear in the DHCPFORCERENEW. I don't think this adds any value from a security perspective, actually, even though it feels more comfortable. I suspect it was put in in the original version simply because of that—why send a secret over the wire when you don't have to? However, the original motivation for using the mechanism from RFC3315 was to avoid defining a new mechanism for a legacy protocol. If we do need to change it, it's going to require a major rework of the document, and a lot of delay, so if it causes no harm, I think that's not worth doing. I concur it's probably not worth changing at this point--but it does inform the is MD5 good enough discussion, which might make it worth mentioning in the security considerations. I too would like to see the text I proposed added to the security considerations, so that we can be clear about what is being accomplished with this draft. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]
Hi Randy and Brian, I am sure the discussion of the discussion has been had before, but: 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 I think that the compatibility issue is a key reason why adoption has been difficult. Others are: No compelling IPv6 only features - From my reading several key features were directed at IPv6 only originally, like IPsec. Successive works to provided all non-address IPv6 features in IPv4. - This in part is being addressed by helpful capabilities such as DHCPv6PD (although we could kill things entirely by back porting this to IPv4 ;-) No local use benefit - Ostensibly deploying IPv6 only gets you (slightly) more work. - compare this to transformative technologies such as Ethernet and IPv4, which had a better price point and enabled new local capabilities, which did not rely on neighbours adopting the same protocol. Of course, these are short-sighted analysis. Being able to uniquely address a peer device is a key benefit which we will see drive adoption once 103.X/8 is gone. Another key benefit is local addressability which handles organizational merges/changes/private peering with ULAs (resolves the RFC-1918 collision problem). For a few years I have been involved in an extremely pragmatic market where people want to see the money they will save by deploying a networking technology. What would get my customers adopting would be a compelling TCO argument. Sincerely, Greg Daley Solutions Architect Logicalis Australia Pty Ltd gda...@au.logicalis.com t +61 3 8532 4042 m +61 401 772 770 ___ 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
On Feb 14, 2012, at 5:23 AM, Maglione Roberta wrote: Please let me know if you have additional comments. Thanks! I think you should change this text in the introduction: The mandatory authentication was originally motivated by a legitimate security concern whereby in some network environments DHCP messages can be spoofed and an attacker could more accurately guess the timing of DHCP renewal messages by first sending a FORCERENEW message. However, in some networks native security mechanisms already provide sufficient protection against spoofing of DHCP traffic. An example of such network is a Broadband Forum TR-101 [TR-101i2] compliant access network. In such environments the mandatory coupling between FORCERENEW and DHCP Authentication [RFC3118] can be relaxed and a lighter authentication mechanism can be used for the FORCERENEW message. To this: [paragraph break] The motivation for making authentication mandatory in DHCPFORCERENEW was to prevent an off-network attacker from taking advantage of DHCPFORCERENEW to accurately predict the timing of a DHCP renewal. Without DHCPFORCERENEW, DHCP renewal timing is under the control of the client, and an off-network attacker has no way of predicting when it will happen, since it doesn't have access to the exchange between the DHCP client and DHCP server. However, the requirement to use the DHCP authentication described in RFC3118 is more stringent than is required for this use case, and has limited adoption of DHCPFORCERENEW. RFC3315 defines an authentication protocol using a nonce to prevent off-network attackers from successfully causing clients to renew. Since the off-network attacker doesn't have access to the nonce, it can't trick the client into renewing at a time of its choosing. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
http://tools.ietf.org/html/draft-weil-shared-transition-space-request-14 +1 I support this draft! Best Regards, Hans -- Hans Thienpondt Technology Engineer Converged Network Engineering Telenet NV Liersesteenweg 4 - box 52 T: +32 15 33 30 24 2800 Mechelen - Belgium * Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen. This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents. Ce courriel et les annexes eventuelles peuvent contenir des informations confidentielles et/ou protegees par des droits de propriete intellectuelle. Ce message est adresse exclusivement e son (ses) destinataire(s). Toute utilisation du contenu de ce message (y compris la reproduction ou diffusion partielle ou complete sous toute forme) par une autre personne que le(s) destinataire(s) est formellement interdite. Si vous avez recu ce message par erreur, veuillez prevenir l'expediteur du message et en detruire le contenu. * ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Variable length internet addresses in TCP/IP: history
On 2/13/2012 7:53 PM, Noel Chiappa wrote: From: Brian E Carpenterbrian.e.carpen...@gmail.com 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! :-) Noel, You probably remember this, but... Within the ARPA-funded Internet research program that designed IP and TCP, Jon Postel and Danny Cohen argued strenuously for variable length addresses. (This must have been around 1979. I cannot name most of the other 10 people in the room, but I have a clear mental picture of Jon, in the back of the room, fuming over this issue. Jon believed intensely in protocol extensibility.) However, Vint Cerf, the ARPA program manager, rules against variable length addresses and decreed the fixed length 32 bit word-aligned addresses of RFC 791. His argument was that TCP/IP had to be simple to implement if it were to succeed (and survive the juggernaut of the ISO OSI protocol suite). System programmers of that day were familiar with word-aligned data structures with fixed offsets, and variable length addresses seemed to be (and in fact would be) harder to program and would make packet dumps harder to interpret. It was a political as much as a technical judgment, and Vint may have been right ... we can never know. We do know that IP eventually succeeded and OSI failed, but it was a near thing for awhile. Of course, there were other factors in the success of IP, such as Berkeley Unix. It is to be noted that when it came time to define IPv6 some 20 years later, the IETF stuck with fixed length internet addresses. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Yet Another Reason?
On 2/2/2012 3:05 PM, Chris Grundemann wrote: Hides the screen, nervous, pays cash... Sounds to me like anyone surfing pr0n at the Internet Cafe is now a suspected terrorist.z You should go spend a week in the border towns in Israel before you make such telling comments like that. Todd On Thu, Feb 2, 2012 at 14:55, Alan Johnston alan.b.johns...@gmail.com wrote: Is this yet another reason not to have IETF meetings in the USA? ;-) http://yro.slashdot.org/story/12/02/02/1719221/do-you-like-online-privacy-you-may-be-a-terrorist The FBI and their would-be tipsters could be flat out trying investigate everyone who uses encryption, anonymizer and privacy tools on the Internet, or changes SIM cards in their mobile phone! At least wearing T-shirts with inscrutable slogans isn't on the list yet or we'd all be rounded up... Seriously - who writes this stuff? - Alan - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
+1, I support this draft… Bill Check On Feb 14, 2012, at 10:08 AM, Thienpondt Hans wrote: http://tools.ietf.org/html/draft-weil-shared-transition-space-request-14 +1 I support this draft! Best Regards, Hans -- Hans Thienpondt Technology Engineer Converged Network Engineering Telenet NV Liersesteenweg 4 - box 52 T: +32 15 33 30 24 2800 Mechelen - Belgium * Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen. This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents. Ce courriel et les annexes eventuelles peuvent contenir des informations confidentielles et/ou protegees par des droits de propriete intellectuelle. Ce message est adresse exclusivement e son (ses) destinataire(s). Toute utilisation du contenu de ce message (y compris la reproduction ou diffusion partielle ou complete sous toute forme) par une autre personne que le(s) destinataire(s) est formellement interdite. Si vous avez recu ce message par erreur, veuillez prevenir l'expediteur du message et en detruire le contenu. * ___ 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: Furthering discussions about BCP79 sanctions
On 2/12/2012 10:12 AM, Adrian Farrel wrote: Hi SM, So isnt the real issue that of informed consent? If you dont know that someone else has already existing work is it their fault for not telling the IETF? If so then there would also need to be some form of process identical to this for verifying that the people participating hold legal power of attorney pertaining to that work for their sponsors, or they cannot make any 'management decisions' pertaining to any project. The misunderstanding in the IETF BCP78 and BCP79 documents is that one-size fits all for IETF participants. It simply cannot - In fact many participants are there to work on processes and efforts for their sponsors who have no legal power of attorney for their sponsors what so ever. This is part of the myriad of misrepresentations that the IETF and its parent ISOC are still trying to get the rest of the world to swallow IMHO. Todd There has been some discussion on this list about draft-farrresnickel-ipr-sanctions-00. Thanks for the input. The conversation seems to be partitioned into: - discussion of sanctions and how to apply them - discussion of measures that can be taken to help people to adhere to BCP79 The following messages are about the help people: http://www.ietf.org/mail-archive/web/ccamp/current/msg13082.html http://www.ietf.org/mail-archive/web/marf/current/msg02081.html Yes. I've been watching those threads, and I think that some other WGs are thinking of following similar procedures. Furthermore, there is some debate about who should/can be responsible for applying sanctions. [snip] In Appendix A: - Does the large number of patents that the individual has authored provide any level of excuse for failing to notice that one of their patents covered the IETF work? That should be the individual has invented. Yes. I suggest removing the above as prolific inventors should pay more attention to BCP 79. I'm inclined to agree with you. Others feel that there may be some mitigation in this case. By listing the point, we are giving the WG chairs the opportunity to consider it. They may deduce that it provides an excuse, no excuse, or exacerbates the case. Section 6.1.2 of BCP 79 is about an IETF Participant's IPR in Contributions by others. Should sanctions be considered if the individual participates and does not disclose? Yes. That is certainly my intention in this document. All violations of BCP 79 are cause to consider sanctions. The severity of the case may be judged by many factors, and I suppose that the level of participation may be one of these factors. I am hoping that Section 2.1 makes the first point clear, and Appendix A the second point. Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Apologies for top posting rather than addressing specific commentators, but there have been several misconceptions raised several times that I felt should be addressed generically: 1) We are out of IPv4 space / There's no-where to get this /10 - There is already a /10 reserved by the ARIN community for this purpose (as long as we don't drag our feet too long), please see: https://www.arin.net/policy/proposals/2011_5.html 2) Just use 1918 space - I apologize for not having more data to share, but I can tell you that I have spoken with numerous network operators and NONE of them are willing to do this. ISPs will NOT use RFC 1918 space, no matter how many times folks scream it from the tops of ivory towers. Operational realities must sometimes trump ideals. 3) CGN is bad - This one is accurate. It has no bearing on this I-D whatsoever though. Yes, CGN sucks and we want as few networks to use it as possible. But, no matter what we do, some will have to deploy it. This I-D is about helping reduce everyone's pain when they do. Leaking squat space hurts more than just the one who leaks it... 4) IPv6 is awesome - Again, accurate but inconsequential here. IPv6 does not solve IPv4 connectivity issues. Operators are not solely responsible for the lack of IPv6 penetration. Rather than throw stones from our glass houses, we should focus on ensuring that the transition can happen without shattering all of them. I understand that many have strong emotional ties to their opinions. My only hope is to point those with open minds in the right direction as they seek to understand this issue more fully. Cheers, ~Chris (speaking for myself, from an ivory tower made of glass) On Mon, Jan 30, 2012 at 16:03, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Reserved IPv4 Prefix for Shared CGN Space' draft-weil-shared-transition-space-request-14.txt as a BCP On its December 15, 2011 telechat, the IESG reviewed version 10 of this document and requested various changes. These changes are reflected in the draft version 14 and the IESG now solicits community input on the changed text only. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-16. 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 This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier Grade Network Address Translation (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premise Equipment (CPE). Shared Address Space is distinct from RFC1918 private address space because it is intended for use on Service Provider networks. However, it may be used as RFC 1918 private address space in certain circumstances. Details are provided in the text of this document. As this document proposes the allocation of an additional special-use IPv4 address block, it updates RFC 5735. The following text captures the most salient change between version 10 and 14 of this document: Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Also, Shared Address Space can be used as additional [RFC1918] space when at least one of the following conditions is true: o Shared Address Space is not also used on the Service Provider side of the CPE. o CPE routers behave correctly when using the same address block on both the internal and external interfaces. The file can be obtained via http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- @ChrisGrundemann http://chrisgrundemann.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Another last call for draft-weil
+1. Ross From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Owen DeLong Sent: Monday, February 13, 2012 2:06 PM To: ietf@ietf.org Cc: draft-bdgks-arin-shared-transition-space@tools. org Subject: Re: Another last call for draft-weil I support draft-weil as revised. There is a vital need for this to move forward and the IETF should stop standing in the way and let ARIN allocate the space already. Owen On Feb 13, 2012, at 10:09 AM, Chris Grundemann wrote: Fellow BDGKS Authors, FYI: draft-weil is in another Last Call following an update that was requested by IESG Ads (on their December telechat, some ADs asked us to turn our request into a request for more 1918 space, but with a few caveats to home router manufacturers about not breaking when exposed to a CGN environment.). At this point we don't expect to change any minds. Basically everyone who is against the draft has spoken up. Now it is just a numbers game, we need to demonstrate significant support for the draft. If you do support this I-D and the allocation of the /10 for shared CGN use, please consider posting a statement of support. Something as simple as I support this draft as updated or I think the updated draft is more flexible, and would satisfy additional use cases that don't work with RFC1918 space would be very helpful. You can respond to the Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP thread or post individually to ietf@ietf.orgmailto:ietf@ietf.org. Also, please feel free to encourage anyone else you know who supports the draft to make a similar post. Every statement we can gather is vital right now. Last call ends on Thursday, so reply's must be made before then. Thank you. Cheers, ~Chris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another last call for draft-weil
(not voting twice, my other address did not seem to work) 1 On Feb 14, 2012, at 1:25 PM, Ross Callon wrote: 1. Ross From:ietf-boun...@ietf.org[mailto:ietf-boun...@ietf.org]On Behalf OfOwen DeLong Sent:Monday, February 13, 2012 2:06 PM To:ietf@ietf.org Cc:draft-bdgks-arin-shared-transition-space@tools. org Subject:Re: Another last call for draft-weil I support draft-weil as revised. There is a vital need for this to move forward and the IETF should stop standing in the way and let ARIN allocate the space already. Owen On Feb 13, 2012, at 10:09 AM, Chris Grundemann wrote: Fellow BDGKS Authors, FYI: draft-weil is in another Last Call following an update that was requested by IESG Ads(on their December telechat, some ADs asked us to turn ourrequest into a request for more 1918 space, but with a few caveats to homerouter manufacturers about not breaking when exposed to a CGN environment.). At this point we don't expect to change any minds. Basically everyone who is against the draft has spoken up. Now it is just a numbers game, we need to demonstrate significant support for the draft. If you do support this I-D and the allocation of the /10 for shared CGN use, please consider posting a statement of support. Something as simple as I support this draft as updated or I thinkthe updated draft is more flexible, and would satisfy additional use casesthat don't work with RFC1918 space would be very helpful. You can respond to the Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP thread or post individually toietf@ietf.org. Also, please feel free to encourage anyone else you know who supports the draft to make a similar post. Every statement we can gather is vital right now. Last call ends on Thursday, so reply's must be made before then. Thank you. Cheers, ~Chris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Scott O Bradner Senior TechnologyConsultant Harvard University Information Technology Innovation Architecture (P) 1 (617) 495 3864 29 Oxford St. Rm 407 Cambridge, MA 02138 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
The word alignment issue was very strong and the router people had considerably more influence than the host folks. I tried to propose variable length addressing using four bit nibbles in August 1974 and I got no traction at all. Steve Sent from my iPhone On Feb 14, 2012, at 6:31 PM, Bob Braden bra...@isi.edu wrote: On 2/13/2012 7:53 PM, Noel Chiappa wrote: From: Brian E Carpenterbrian.e.carpen...@gmail.com 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! :-) Noel, You probably remember this, but... Within the ARPA-funded Internet research program that designed IP and TCP, Jon Postel and Danny Cohen argued strenuously for variable length addresses. (This must have been around 1979. I cannot name most of the other 10 people in the room, but I have a clear mental picture of Jon, in the back of the room, fuming over this issue. Jon believed intensely in protocol extensibility.) However, Vint Cerf, the ARPA program manager, rules against variable length addresses and decreed the fixed length 32 bit word-aligned addresses of RFC 791. His argument was that TCP/IP had to be simple to implement if it were to succeed (and survive the juggernaut of the ISO OSI protocol suite). System programmers of that day were familiar with word-aligned data structures with fixed offsets, and variable length addresses seemed to be (and in fact would be) harder to program and would make packet dumps harder to interpret. It was a political as much as a technical judgment, and Vint may have been right ... we can never know. We do know that IP eventually succeeded and OSI failed, but it was a near thing for awhile. Of course, there were other factors in the success of IP, such as Berkeley Unix. It is to be noted that when it came time to define IPv6 some 20 years later, the IETF stuck with fixed length internet addresses. Bob Braden ___ 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: Variable length internet addresses in TCP/IP: history
in the case of IPng, the router people wanted variable length but the host people (or at least some of them) did not Scott Scott O Bradner Senior TechnologyConsultant Harvard University Information Technology Innovation Architecture (P) 1 (617) 495 3864 29 Oxford St. Rm 407 Cambridge, MA 02138 On Feb 14, 2012, at 1:34 PM, Steve Crocker wrote: The word alignment issue was very strong and the router people had considerably more influence than the host folks. I tried to propose variable length addressing using four bit nibbles in August 1974 and I got no traction at all. Steve Sent from my iPhone On Feb 14, 2012, at 6:31 PM, Bob Braden bra...@isi.edu wrote: On 2/13/2012 7:53 PM, Noel Chiappa wrote: From: Brian E Carpenterbrian.e.carpen...@gmail.com 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! :-) Noel, You probably remember this, but... Within the ARPA-funded Internet research program that designed IP and TCP, Jon Postel and Danny Cohen argued strenuously for variable length addresses. (This must have been around 1979. I cannot name most of the other 10 people in the room, but I have a clear mental picture of Jon, in the back of the room, fuming over this issue. Jon believed intensely in protocol extensibility.) However, Vint Cerf, the ARPA program manager, rules against variable length addresses and decreed the fixed length 32 bit word-aligned addresses of RFC 791. His argument was that TCP/IP had to be simple to implement if it were to succeed (and survive the juggernaut of the ISO OSI protocol suite). System programmers of that day were familiar with word-aligned data structures with fixed offsets, and variable length addresses seemed to be (and in fact would be) harder to program and would make packet dumps harder to interpret. It was a political as much as a technical judgment, and Vint may have been right ... we can never know. We do know that IP eventually succeeded and OSI failed, but it was a near thing for awhile. Of course, there were other factors in the success of IP, such as Berkeley Unix. It is to be noted that when it came time to define IPv6 some 20 years later, the IETF stuck with fixed length internet addresses. Bob Braden ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
To the addressed folks who's messages appear below: I'm not sure I understand what you're saying. There was some objection at the beginning of this thread by Wes George, Noel Chiappa, and Brian Carpenter. I agreed that the document could be misunderstood as encouraging the use of the space as 1918 space and proposed some replacement text. There seemed to be some agreement around that text. Are you now objecting to that replacement text and want -14 published as is? Do you think the document should say that the new allocation can be used as 1918 space? If so, please explain. pr On 2/14/12 8:54 AM, Donald Eastlake wrote: I also support this draft. On 2/14/12 9:06 AM, ned+i...@mauve.mrochek.com wrote: On Tuesday, February 14, 2012, Daryl Tannerdaryl.tan...@blueyonder.co.uk mailto:daryl.tan...@blueyonder.co.uk wrote: I support this updated draft, and I am keen for this to be published as a BCP. +1 I believe the amendments in this revision clarify the usage and intended purpose of the shared transition space. +1 On 2/14/12 10:19 AM, jeff.finkelst...@cox.com wrote: I support this draft as updated. On 2/13/12 1:05 PM, Owen DeLong wrote: I support draft-weil as revised. There is a vital need for this to move forward and the IETF should stop standing in the way and let ARIN allocate the space already. On 2/14/12 12:25 PM, Ross Callon wrote: +1 -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another last call for draft-weil
I'm curious: how is the IETF stopping ARIN from allocating the space? Thanks, -drc On Feb 14, 2012, at 10:33 AM, Bradner, Scott wrote: (not voting twice, my other address did not seem to work) +1 On Feb 14, 2012, at 1:25 PM, Ross Callon wrote: +1. Ross From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Owen DeLong Sent: Monday, February 13, 2012 2:06 PM To: ietf@ietf.org Cc: draft-bdgks-arin-shared-transition-space@tools. org Subject: Re: Another last call for draft-weil I support draft-weil as revised. There is a vital need for this to move forward and the IETF should stop standing in the way and let ARIN allocate the space already. Owen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another last call for draft-weil
the IAB advised ARIN that such assignments were in the purview of the IETF Scott Scott O Bradner Senior TechnologyConsultant Harvard University Information Technology Innovation Architecture (P) 1 (617) 495 3864 29 Oxford St. Rm 407 Cambridge, MA 02138 On Feb 14, 2012, at 1:49 PM, David Conrad wrote: I'm curious: how is the IETF stopping ARIN from allocating the space? Thanks, -drc On Feb 14, 2012, at 10:33 AM, Bradner, Scott wrote: (not voting twice, my other address did not seem to work) 1 On Feb 14, 2012, at 1:25 PM, Ross Callon wrote: 1. Ross From:ietf-boun...@ietf.org[mailto:ietf-boun...@ietf.org]On Behalf OfOwen DeLong Sent:Monday, February 13, 2012 2:06 PM To:ietf@ietf.org Cc:draft-bdgks-arin-shared-transition-space@tools. org Subject:Re: Another last call for draft-weil I support draft-weil as revised. There is a vital need for this to move forward and the IETF should stop standing in the way and let ARIN allocate the space already. Owen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another last call for draft-weil
On Tue, Feb 14, 2012 at 1:49 PM, David Conrad d...@virtualized.org wrote: I'm curious: how is the IETF stopping ARIN from allocating the space? +1 though honestly I'm not a fan of the process. Thanks, -drc On Feb 14, 2012, at 10:33 AM, Bradner, Scott wrote: (not voting twice, my other address did not seem to work) +1 On Feb 14, 2012, at 1:25 PM, Ross Callon wrote: +1. Ross From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Owen DeLong Sent: Monday, February 13, 2012 2:06 PM To: ietf@ietf.org Cc: draft-bdgks-arin-shared-transition-space@tools. org Subject: Re: Another last call for draft-weil I support draft-weil as revised. There is a vital need for this to move forward and the IETF should stop standing in the way and let ARIN allocate the space already. Owen ___ 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: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
To the addressed folks who's messages appear below: I'm not sure I understand what you're saying. There was some objection at the beginning of this thread by Wes George, Noel Chiappa, and Brian Carpenter. I agreed that the document could be misunderstood as encouraging the use of the space as 1918 space and proposed some replacement text. There seemed to be some agreement around that text. Are you now objecting to that replacement text and want -14 published as is? Do you think the document should say that the new allocation can be used as 1918 space? If so, please explain. Not sure how a +1 to a statement saying I support this updated draft, and I am keen for this to be published as a BCP. can be interpreted in any but one way, or for that matter how it can be stated much differently. Anyway, to use different words, I would like to see the current draft approved and published as a BCP. Clear enough? Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Pete Resnick wrote: I'm not sure I understand what you're saying. There was some objection at the beginning of this thread by Wes George, Noel Chiappa, and Brian Carpenter. I agreed that the document could be misunderstood as encouraging the use of the space as 1918 space and proposed some replacement text. There seemed to be some agreement around that text. Are you now objecting to that replacement text and want -14 published as is? Do you think the document should say that the new allocation can be used as 1918 space? If so, please explain. On the first hand, I do support draft-weil. I think I understand the use cases enough to see that it *is* required, especially for large MSO's, and potentially larger enterprises. On the other hand, I can see the confusion regarding using RFC-1918 space *for this purpose* vs use this space as *additional RFC-1918*. The former just doesn't work due to unmanaged overlap. The latter *seems* like it should work, but if you play it out until the first vendor starts releasing equipment that uses it, you've now joined the first-case scenerio. On the gripping hand, I hate the back-and-forth quibbling over the tiniest motes, hoping that the delays will just make the problem disappear... So yes, lets please move this draft forward, with the text cleaning stating that it NOT be used as RFC-1918 space. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/14/12 1:50 PM, ned+i...@mauve.mrochek.com wrote: Are you now objecting to that replacement text and want -14 published as is? Do you think the document should say that the new allocation can be used as 1918 space? If so, please explain. Not sure how a +1 to a statement saying I support this updated draft, and I am keen for this to be published as a BCP. can be interpreted in any but one way, or for that matter how it can be stated much differently. Anyway, to use different words, I would like to see the current draft approved and published as a BCP. Clear enough? Nope. Perhaps my question was unclear. I'll try and ask my question again with different words: Do you, or do you not, object to the proposed change that changes the text from saying, This space may be used just as 1918 space to This space has limitations and cannot be used as 1918 space? Nobody on the list objected to that new text. That new text significantly changes -14. You have stated your support for -14. Do you object to changing the text? pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/14/12 1:50 PM, ned+i...@mauve.mrochek.com wrote: Are you now objecting to that replacement text and want -14 published as is? Do you think the document should say that the new allocation can be used as 1918 space? If so, please explain. Not sure how a +1 to a statement saying I support this updated draft, and I am keen for this to be published as a BCP. can be interpreted in any but one way, or for that matter how it can be stated much differently. Anyway, to use different words, I would like to see the current draft approved and published as a BCP. Clear enough? Nope. Perhaps my question was unclear. I'll try and ask my question again with different words: Do you, or do you not, object to the proposed change that changes the text from saying, This space may be used just as 1918 space to This space has limitations and cannot be used as 1918 space? Nobody on the list objected to that new text. That new text significantly changes -14. You have stated your support for -14. Do you object to changing the text? I assumed the proposed change was in the current draft - isn't that how it's supposed to be done? Anyway, I think the change is fine, but I also think the draft is acceptable without it. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Do you, or do you not, object to the proposed change that changes the text from saying, This space may be used just as 1918 space to This space has limitations and cannot be used as 1918 space? what silliness. it will be used as rfc 1918 space no matter what the document says. nine years ago i was in bologna and did a traceroute out. i was surprised to find that the isp was using un-announced us military space as rfc 1918 space internal to their network. this turns out to be common. any thought that this is not just adding to rfc 1918 is pure bs. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Reminder: T-shirt Design Contest for IETF 83
This is a reminder that the IAOC is conducting a T-Shirt Design Contest to develop a unique t-shirt for the Paris meeting. You have until this Friday, Feb 17 to submit your design for consideration. We've received two submissions so far and you can see them here: http://www.ietf.org/meeting/83/t-shirt-design-contest-submissions.html. If you have design skills, or can strongarm someone else who does, please view this as an opportunity to show your support for the IETF. The Secretariat will take care of producing the shirts once the winning design is selected, and the purchase price (approximately $25 USD) will go to support the IETF. Whoever submits the winning design will receive a free t-shirt. Please send your design to tshirtcont...@ietf.org. Designs should be delivered as EPS or Adobe Illustrator files. A t-shirt template is available for download here: ietf.org/meeting/83/t-shirt-contest-template.eps. Your submission should include t-shirt color, and the design for both front and back of the shirt. Please note: designs should include the IETF logo, but cannot include any company logos. Like an Internet-Draft, a t-shirt design submission is authored by individuals. Regards, Alexa -- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Randy Bush writes: in response to Pete Resnick, who wrote: Do you, or do you not, object to the proposed change that changes the text from saying, This space may be used just as 1918 space to This space has limitations and cannot be used as 1918 space? what silliness. it will be used as rfc 1918 space no matter what the document says. nine years ago i was in bologna and did a traceroute out. i was surprised to find that the isp was using un-announced us military space as rfc 1918 space internal to their network. this turns out to be common. any thought that this is not just adding to rfc 1918 is pure bs. In that I completely agree with what Randy is saying, the point that needs to be made is that this should not be officially sanctioned as RFC-1918 space -- no manufacturer or programmer should treat this netblock the same. If some fly-by-night company chooses to use it on their own, well, then they have chosen to operate outside the bounds of the best-principles - exactly the same as in Randy's example. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2012-02-15 09:35, Randy Bush wrote: Do you, or do you not, object to the proposed change that changes the text from saying, This space may be used just as 1918 space to This space has limitations and cannot be used as 1918 space? what silliness. it will be used as rfc 1918 space no matter what the document says. Of course it will. My suggestion was to change the text to is not intended to be used instead of can be used, hoping that would be viewed as a fair warning. http://www.ietf.org/mail-archive/web/ietf/current/msg71596.html Brian nine years ago i was in bologna and did a traceroute out. i was surprised to find that the isp was using un-announced us military space as rfc 1918 space internal to their network. this turns out to be common. any thought that this is not just adding to rfc 1918 is pure bs. randy ___ 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: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
In that I completely agree with what Randy is saying, the point that needs to be made is that this should not be officially sanctioned as RFC-1918 space -- no manufacturer or programmer should treat this netblock the same. If some fly-by-night company chooses to use it on their own, well, then they have chosen to operate outside the bounds of the best-principles - exactly the same as in Randy's example. and the packets will be very ashamed, right? we can say all the crap we want, but it will be used as 1918 space and, like 1918 space, bgp announcesments of it will leak. get over it. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Furthering discussions about BCP79 sanctions
Todd, You may or may not be right about whether an individual can make a decision to disclose. In my experience they often can't, but do have the power to request/implore their employer to disclose. On the other hand, they *do* have the power to not participate. BCP79 offers this choice and I make no comment about which is preferable. However, it is clear from BCP79 that individuals have the choice and the responsibility to choose. Thanks, Adrian -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of todd glassey Sent: 14 February 2012 17:43 To: ietf@ietf.org Subject: Re: Furthering discussions about BCP79 sanctions On 2/12/2012 10:12 AM, Adrian Farrel wrote: Hi SM, So isnt the real issue that of informed consent? If you dont know that someone else has already existing work is it their fault for not telling the IETF? If so then there would also need to be some form of process identical to this for verifying that the people participating hold legal power of attorney pertaining to that work for their sponsors, or they cannot make any 'management decisions' pertaining to any project. The misunderstanding in the IETF BCP78 and BCP79 documents is that one-size fits all for IETF participants. It simply cannot - In fact many participants are there to work on processes and efforts for their sponsors who have no legal power of attorney for their sponsors what so ever. This is part of the myriad of misrepresentations that the IETF and its parent ISOC are still trying to get the rest of the world to swallow IMHO. Todd There has been some discussion on this list about draft-farrresnickel-ipr-sanctions-00. Thanks for the input. The conversation seems to be partitioned into: - discussion of sanctions and how to apply them - discussion of measures that can be taken to help people to adhere to BCP79 The following messages are about the help people: http://www.ietf.org/mail-archive/web/ccamp/current/msg13082.html http://www.ietf.org/mail-archive/web/marf/current/msg02081.html Yes. I've been watching those threads, and I think that some other WGs are thinking of following similar procedures. Furthermore, there is some debate about who should/can be responsible for applying sanctions. [snip] In Appendix A: - Does the large number of patents that the individual has authored provide any level of excuse for failing to notice that one of their patents covered the IETF work? That should be the individual has invented. Yes. I suggest removing the above as prolific inventors should pay more attention to BCP 79. I'm inclined to agree with you. Others feel that there may be some mitigation in this case. By listing the point, we are giving the WG chairs the opportunity to consider it. They may deduce that it provides an excuse, no excuse, or exacerbates the case. Section 6.1.2 of BCP 79 is about an IETF Participant's IPR in Contributions by others. Should sanctions be considered if the individual participates and does not disclose? Yes. That is certainly my intention in this document. All violations of BCP 79 are cause to consider sanctions. The severity of the case may be judged by many factors, and I suppose that the level of participation may be one of these factors. I am hoping that Section 2.1 makes the first point clear, and Appendix A the second point. Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. ___ 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: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Randy Bush writes: in response to me: In that I completely agree with what Randy is saying, the point that needs to be made is that this should not be officially sanctioned as RFC-1918 space -- no manufacturer or programmer should treat this netblock the same. If some fly-by-night company chooses to use it on their own, well, then they have chosen to operate outside the bounds of the best-principles - exactly the same as in Randy's example. and the packets will be very ashamed, right? we can say all the crap we want, but it will be used as 1918 space and, like 1918 space, bgp announcesments of it will leak. get over it. And that's fine -- on a per-operator basis -- they chose their path. What we're trying to avoid by explicitly NOT marking this as RFC-1918 space is VENDORS using it inside their equipment, thereby negating the entire practical use of the space. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Furthering discussions about BCP79 sanctions
I agree with Adrian. Individuals come to the IETF, not companies. Sure they are employed by companies, but they also have to follow the rules stated in BCP79. I am really tired of the myriad of excuses people have given in the past about why they have not been able to comply. Its a really, really simple thing to read and understand the rules about the IETF's IPR policy BEFORE you submit a draft (or speak at a meeting), and WG chairs go out of their way to give people a number of warnings and reminders about this. If after all of that you disagree, then go home. --Tom Todd, You may or may not be right about whether an individual can make a decision to disclose. In my experience they often can't, but do have the power to request/implore their employer to disclose. On the other hand, they *do* have the power to not participate. BCP79 offers this choice and I make no comment about which is preferable. However, it is clear from BCP79 that individuals have the choice and the responsibility to choose. Thanks, Adrian -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of todd glassey Sent: 14 February 2012 17:43 To: ietf@ietf.org Subject: Re: Furthering discussions about BCP79 sanctions On 2/12/2012 10:12 AM, Adrian Farrel wrote: Hi SM, So isnt the real issue that of informed consent? If you dont know that someone else has already existing work is it their fault for not telling the IETF? If so then there would also need to be some form of process identical to this for verifying that the people participating hold legal power of attorney pertaining to that work for their sponsors, or they cannot make any 'management decisions' pertaining to any project. The misunderstanding in the IETF BCP78 and BCP79 documents is that one-size fits all for IETF participants. It simply cannot - In fact many participants are there to work on processes and efforts for their sponsors who have no legal power of attorney for their sponsors what so ever. This is part of the myriad of misrepresentations that the IETF and its parent ISOC are still trying to get the rest of the world to swallow IMHO. Todd There has been some discussion on this list about draft-farrresnickel-ipr-sanctions-00. Thanks for the input. The conversation seems to be partitioned into: - discussion of sanctions and how to apply them - discussion of measures that can be taken to help people to adhere to BCP79 The following messages are about the help people: http://www.ietf.org/mail-archive/web/ccamp/current/msg13082.html http://www.ietf.org/mail-archive/web/marf/current/msg02081.html Yes. I've been watching those threads, and I think that some other WGs are thinking of following similar procedures. Furthermore, there is some debate about who should/can be responsible for applying sanctions. [snip] In Appendix A: - Does the large number of patents that the individual has authored provide any level of excuse for failing to notice that one of their patents covered the IETF work? That should be the individual has invented. Yes. I suggest removing the above as prolific inventors should pay more attention to BCP 79. I'm inclined to agree with you. Others feel that there may be some mitigation in this case. By listing the point, we are giving the WG chairs the opportunity to consider it. They may deduce that it provides an excuse, no excuse, or exacerbates the case. Section 6.1.2 of BCP 79 is about an IETF Participant's IPR in Contributions by others. Should sanctions be considered if the individual participates and does not disclose? Yes. That is certainly my intention in this document. All violations of BCP 79 are cause to consider sanctions. The severity of the case may be judged by many factors, and I suppose that the level of participation may be one of these factors. I am hoping that Section 2.1 makes the first point clear, and Appendix A the second point. Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Bob Braden wrote: Within the ARPA-funded Internet research program that designed IP and TCP, Jon Postel and Danny Cohen argued strenuously for variable length addresses. (This must have been around 1979. I cannot name most of the other 10 people in the room, but I have a clear mental picture of Jon, in the back of the room, fuming over this issue. Jon believed intensely in protocol extensibility.) However, Vint Cerf, the ARPA program manager, rules against variable length addresses and decreed the fixed length 32 bit word-aligned addresses of RFC 791. His argument was that TCP/IP had to be simple to implement if it were to succeed (and survive the juggernaut of the ISO OSI protocol suite). I'm quite OK with both, IPv4 fixed-length 32-bit addresses and IPv6 fixed-length 128-bit addresses, and consider fixed-length addresses reasonable. What I really don't like is that IPv6 was not made to be transparently backwards compatible (on the IPv4 address range), but instead a completely different protocol that requires non-trivial translation IPv4-IPv6. One the one hand, the IETF was frowning upon NATs when they were developed outside of the IETF. But if you look at the IETFs (lack of) migration plan, the translation that you need in order to make old-IPv4 interoperate with new-IPv6, is actually worse than an IPv4 NAT. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Martin, One the one hand, the IETF was frowning upon NATs when they were developed outside of the IETF. But if you look at the IETFs (lack of) migration plan, the translation that you need in order to make old-IPv4 interoperate with new-IPv6, is actually worse than an IPv4 NAT. I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, address mapping, and translation. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support 32 bit addresses, you have the problem. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Brian E Carpenter wrote: Martin, One the one hand, the IETF was frowning upon NATs when they were developed outside of the IETF. But if you look at the IETFs (lack of) migration plan, the translation that you need in order to make old-IPv4 interoperate with new-IPv6, is actually worse than an IPv4 NAT. I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, address mapping, and translation. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support 32 bit addresses, you have the problem. But what is your point? With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. You would not have two distinct routing tables for two independent Internets, but a single routing table for a single Internet. And the first network interfaces that would be using 32-bit IP-addresses exclusively would have been networking equipment of ISPs that does not need to be IPv4-addressable by everyone and his dog anyway (that is not so much different from the /10 shared address space that CGNs will be using). The necessary changes to applications would be minimal, the happy eyeballs contortion completely unnecessary and the security assessment for an IPv6 enabled network *MUCH* simpler. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
In message 201202142245.q1emjaou019...@fs4113.wdf.sap.corp, Martin Rex writes : The necessary changes to applications would be minimal, the happy eyeballs contortion completely unnecessary and the security assessment for an IPv6 enabled network *MUCH* simpler. Happy eyeballs just points out problems with multi-homing in general. IPv4 has the *same* problem and sites spend 1000's of dollars working around the issue which could have been addressed with a couple of extra lines of code on the client side in most cases. Mark -- 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: Variable length internet addresses in TCP/IP: history
Martin, On Feb 14, 2012, at 2:45 PM, Martin Rex wrote: Brian E Carpenter wrote: Martin, One the one hand, the IETF was frowning upon NATs when they were developed outside of the IETF. But if you look at the IETFs (lack of) migration plan, the translation that you need in order to make old-IPv4 interoperate with new-IPv6, is actually worse than an IPv4 NAT. I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, address mapping, and translation. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support 32 bit addresses, you have the problem. But what is your point? With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. Right, just like they could have deployed dual stack many years ago too. The deployment problem was not due to technical issues, it was because the Internet changed to only deploy new technology that generated revenue in the short term. After a lot of thought, I have come to the conclusion that it wouldn't have mattered what the IETF did, we would still be facing the same problems. It wouldn't be seriously deployed until IPv4 address ran out. These if we had only done foo discussions all miss the biggest deployment factor. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Brian E Carpenter wrote: I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, Sure. address mapping, and translation. Not at all. Realm Specific IP [RFC3102] is such an example without any mapping nor translations. Abstract of the RFC states: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support32 bit addresses, you have the problem. The only problem is that some people misinterpret it that we had needed IPv6. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
Mark Andrews wrote: Happy eyeballs just points out problems with multi-homing in general. IPv4 has the *same* problem and sites spend 1000's of dollars working around the issue which could have been addressed with a couple of extra lines of code on the client side in most cases. It's Brian Carpenter who refused to discuss such issues in MULTI6 WG. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Let ARIN decide (was Re: Another last call for draft-weil)
Bradner, Scott wrote: the IAB advised ARIN that such assignments were in the purview of the IETF Then, isn't it enough for IETF to conclude let ARIN decide? Are there any objections to conclude so? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
The deployment problem was not due to technical issues, it was because the Internet changed to only deploy new technology that generated revenue in the short term. After a lot of thought, I have come to the conclusion that it wouldn't have mattered what the IETF did, we would still be facing the same problems. It wouldn't be seriously deployed until IPv4 address ran out. perhaps 'engineering' includes thinking about the costs of deployment. perhaps backward compatibility would have reduced the costs. randy, whose $dayjob did deploy very early ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt
Pete Resnick wrote: Do you, or do you not, object to the proposed change that changes the text from saying, This space may be used just as 1918 space to This space has limitations and cannot be used as 1918 space? Nobody on the list objected to that new text. That new text significantly changes -14. You have stated your support for -14. Do you object to changing the text? I support the document _with_ that proposed change to discourage the (ab)use of that ARIN /10 CGN space as 1918 space. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/14/12 2:35 PM, Randy Bush wrote: what silliness. it will be used as rfc 1918 space no matter what the document says. [...] any thought that this is not just adding to rfc 1918 is pure bs. Of course it will be used as 1918 space. That's not the point of the text. The text is saying, You could read 1918 to say that we somehow promised that you would never be connected to a network run by someone other than yourself and see 1918 addresses on it. That's not an entirely intelligent reading, but we see how you can read it that way. So, if you built yourself a device where it isn't able to deal with 1918 addresses on its 'outside' interface that you were using on the 'inside' interfaces, we could see how that might happen. It was not at all smart of you to build your device that way, but you probably were technically within spec. Now we're adding some address space to the pool. It's not global and it's not routable, just the same as 1918 space. But we're letting you know right now: You *will* see these addresses on networks that you don't run. If you want to use this space the way that you used 1918 space, peachy, but understand that if you're unable to deal with these addresses duplicating ones you're using, your device is toast. Deal with it. Any thought that the text is saying something more than this is nonsense. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Randy Bush wrote: what silliness. it will be used as rfc 1918 space no matter what the document says. The difference is on how future conflicts can be resolved. nine years ago i was in bologna and did a traceroute out. i was surprised to find that the isp was using un-announced us military space as rfc 1918 space internal to their network. this turns out to be common. What if the military space is sold to public and announced? Who is forced to renumber and why? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 12-02-14 3:49 PM, Randy Bush ra...@psg.com wrote: In that I completely agree with what Randy is saying, the point that needs to be made is that this should not be officially sanctioned as RFC-1918 space -- no manufacturer or programmer should treat this netblock the same. If some fly-by-night company chooses to use it on their own, well, then they have chosen to operate outside the bounds of the best-principles - exactly the same as in Randy's example. and the packets will be very ashamed, right? we can say all the crap we want, but it will be used as 1918 space and, like 1918 space, bgp announcesments of it will leak. get over it. Sure, but with a well known address range, it's not just what one AS leaks.. The other AS(s) can also block incoming. That's one of the benefits of a well known space for this. For squat, good luck figuring out who is using what from where. Victor K randy ___ 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: Last call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Support Draft as written +1. Victor K On 12-02-14 12:38 PM, William Check bch...@ncta.com wrote: +1, I support this draft Bill Check On Feb 14, 2012, at 10:08 AM, Thienpondt Hans wrote: http://tools.ietf.org/html/draft-weil-shared-transition-space-request-14 +1 I support this draft! Best Regards, Hans -- Hans Thienpondt Technology Engineer Converged Network Engineering Telenet NV Liersesteenweg 4 - box 52 T: +32 15 33 30 24 2800 Mechelen - Belgium * Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen. This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents. Ce courriel et les annexes eventuelles peuvent contenir des informations confidentielles et/ou protegees par des droits de propriete intellectuelle. Ce message est adresse exclusivement e son (ses) destinataire(s). Toute utilisation du contenu de ce message (y compris la reproduction ou diffusion partielle ou complete sous toute forme) par une autre personne que le(s) destinataire(s) est formellement interdite. Si vous avez recu ce message par erreur, veuillez prevenir l'expediteur du message et en detruire le contenu. * ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On 2012-02-15 11:45, Martin Rex wrote: Brian E Carpenter wrote: Martin, One the one hand, the IETF was frowning upon NATs when they were developed outside of the IETF. But if you look at the IETFs (lack of) migration plan, the translation that you need in order to make old-IPv4 interoperate with new-IPv6, is actually worse than an IPv4 NAT. I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, address mapping, and translation. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support 32 bit addresses, you have the problem. But what is your point? With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. Why? They would have needed updated stacks. The routers would have need updated stacks. The servers would have needed updated stacks. The firewalls would have needed updated stacks. The load balancers would have needed updated stacks. Many MIBs would have needed to be updated. DHCP servers would have needed to be updated. ARP would have needed to be updated, and every routing protocol. Why would the economic incentives have been significantly different? You would not have two distinct routing tables for two independent Internets, but a single routing table for a single Internet. True, but why is this a particular advantage? It wouldn't have affected the need for an update to BGP4, for example. And the first network interfaces that would be using 32-bit IP-addresses exclusively would have been networking equipment of ISPs that does not need to be IPv4-addressable by everyone and his dog anyway (that is not so much different from the /10 shared address space that CGNs will be using). Neither is it so much different from dual stack routing, which has been working for, what, 15 years now? I don't see the comparison with CGN though, which is a carefully engineered single bottleneck of failure, in contrast to dynamic routing. The necessary changes to applications would be minimal, the happy eyeballs contortion completely unnecessary As someone else said, this is to do with multihoming and multi-interfacing; the fact that there are two address lengths is a side-issue. We would still have needed to update the socket interface to deal with 32 bit addresses, and ditto the DNS. and the security assessment for an IPv6 enabled network *MUCH* simpler. I agree that the fact that IPv6 has a different feature list from IPv4 has provided entertainment for security analysts. I will shut up on this topic and get back to IPv6 deployment. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/14/2012 17:26, Pete Resnick wrote: Of course it will be used as 1918 space. That's not the point of the text. My first reply in this most recent version of the thread pointed out that now that we're finally willing to admit that if a new block is issued it will be used as 1918 space then that leads to the obvious conclusion that the *best* we can do with this draft is to kick the can down the road, which is not enough justification for actually doing the allocation. I'll resist the urge to repeat the other points that I've already repeated too often. :) -- 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: Variable length internet addresses in TCP/IP: history
Why? They would have needed updated stacks. The routers would have need updated stacks. The servers would have needed updated stacks. The firewalls would have needed updated stacks. The load balancers would have needed updated stacks. Many MIBs would have needed to be updated. DHCP servers would have needed to be updated. ARP would have needed to be updated, and every routing protocol. rant the routers had v6 code in the mid to late '90s. servers had the kame stack before then. etc etc etc. except for dhcp, of course, as the v6 religious zealots did not want to allow dhcp, it would make enterprise conversion too easy. what we did not have was a way to deploy around the fracking incompatibility. it was not until 2001 or so that we could even run useful dual stack, so we early deployers had two parallel networks for some years. religion has always been more important to the ietf than deployment. look at dhcpv6, the zealots are still stonewalling router discovery. look at the deprecation of nat-pt, now nat64/dns64. it is as if the ipv6 high priesthood did everything in their power to make ipv6 undeployable without very high cost. and they have succeeded admirably. so today, since the costs of ipv6 incompatibility and lack of feature parity are still high, for some folk it is easier to deploy nat4. what a win for the internet. congratulations. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On Feb 14, 2012 7:40 PM, Randy Bush ra...@psg.com wrote: Why? They would have needed updated stacks. The routers would have need updated stacks. The servers would have needed updated stacks. The firewalls would have needed updated stacks. The load balancers would have needed updated stacks. Many MIBs would have needed to be updated. DHCP servers would have needed to be updated. ARP would have needed to be updated, and every routing protocol. rant the routers had v6 code in the mid to late '90s. servers had the kame stack before then. etc etc etc. except for dhcp, of course, as the v6 religious zealots did not want to allow dhcp, it would make enterprise conversion too easy. what we did not have was a way to deploy around the fracking incompatibility. it was not until 2001 or so that we could even run useful dual stack, so we early deployers had two parallel networks for some years. religion has always been more important to the ietf than deployment. look at dhcpv6, the zealots are still stonewalling router discovery. look at the deprecation of nat-pt, now nat64/dns64. it is as if the ipv6 high priesthood did everything in their power to make ipv6 undeployable without very high cost. and they have succeeded admirably. so today, since the costs of ipv6 incompatibility and lack of feature parity are still high, for some folk it is easier to deploy nat4. what a win for the internet. congratulations. randy /rant But, this pig too shall fly Cb ___ 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: Variable length internet addresses in TCP/IP: history
Brian E Carpenter wrote: With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. Why? They would have needed updated stacks. The routers would have need updated stacks. The servers would have needed updated stacks. The firewalls would have needed updated stacks. The load balancers would have needed updated stacks. Many MIBs would have needed to be updated. DHCP servers would have needed to be updated. ARP would have needed to be updated, and every routing protocol. With Realm Specific IP [RFC3102]: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. what is necessary are minor modification on IPv4/transport stack of new (but not existing) hosts and minor extension of DHCP. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt
Victor Kuarsingh wrote: Randy Bush ra...@psg.com wrote: In that I completely agree with what Randy is saying, the point that needs to be made is that this should not be officially sanctioned as RFC-1918 space -- no manufacturer or programmer should treat this netblock the same. If some fly-by-night company chooses to use it on their own, well, then they have chosen to operate outside the bounds of the best-principles - exactly the same as in Randy's example. and the packets will be very ashamed, right? we can say all the crap we want, but it will be used as 1918 space and, like 1918 space, bgp announcesments of it will leak. get over it. Sure, but with a well known address range, it's not just what one AS leaks.. The other AS(s) can also block incoming. That's one of the benefits of a well known space for this. For squat, good luck figuring out who is using what from where. Considering the huge amounts of unused IPv4 address space, why is there a need for squat space at all? Out of curiosity, I tried to configure interface addresses from 0/8 or 240/4, but neither my Linux nor my Windows boxen allowed me that. And lots of CPEs are based on Linux. And a lot of that equiment is used _much_ longer than its firmware is maintained by its vendor! Any idea how long it takes to grow such hardwired restrictions out of an installed base? I wish there was more forward thinking among implementors. One can not complain about the squat use of *assigned* space when all of the unassigned address ranges have been made totally unusable by implementors of IPv4 network stacks. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On Feb 15, 2012, at 1:56 AM, Bob Hinden wrote: Martin, On Feb 14, 2012, at 2:45 PM, Martin Rex wrote: Brian E Carpenter wrote: Martin, One the one hand, the IETF was frowning upon NATs when they were developed outside of the IETF. But if you look at the IETFs (lack of) migration plan, the translation that you need in order to make old-IPv4 interoperate with new-IPv6, is actually worse than an IPv4 NAT. I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, address mapping, and translation. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support 32 bit addresses, you have the problem. But what is your point? With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. Right, just like they could have deployed dual stack many years ago too. The deployment problem was not due to technical issues, it was because the Internet changed to only deploy new technology that generated revenue in the short term. After a lot of thought, I have come to the conclusion that it wouldn't have mattered what the IETF did, we would still be facing the same problems. It wouldn't be seriously deployed until IPv4 address ran out. These if we had only done foo discussions all miss the biggest deployment factor. I disagree with that. With things that take considerable effort to develop and deploy, any sane business or agency would do a cost/benefit analysis, and not deploy unless they can see how it pays off. Smaller projects sometimes go under the radar. Maybe the cost-benefit analysis says it's not worth doing a cost-benefit analysis. When investment is low, people do things even without assurances that those would in fact be needed. I'll leave example from our employer out of this thread. If adding support for the next IP version in products was easy (say, 1-2 man-years for an OS, and 1-2 man months for an application), then Windows XP, Mac OS 10.1 and whatever Linux was running at the time and Solaris 2.9 would have had the support, and applications would follow quickly, long before IPv4 addresses became scarce. Yoav ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services
A new IETF non-working group email list has been created. List address: s...@ietf.org Archive: http://www.ietf.org/mail-archive/web/sop/ To subscribe: https://www.ietf.org/mailman/listinfo/sop Purpose: Cloud services need to interoperate across cloud providers, service vendors and private/public domains. To enable this interoperability, there is need for a standard wire-format for exchanging service information. This mailing lists is for discussing protocols, data formats and server descriptions formats that allow cloud services to be discovered and used across private and public domains. Using these, it would be possible to interoperate diverse APIs and cloud services across service providers, service vendors and service users. For additional information, please contact the list administrators. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Major upgrade to the IETF Datatracker
Shortly, the IETF datatracker will go through a major change, one of the two largest since it was first deployed more than 10 years ago. Hopefully no one will notice. The previous major change was in 2007, when we switched the public Datatracker from Perl cgi-bin scripts to a much more modern and safe implementation based on the Django web application framework. Very few people noticed that change at the time. In a few days, we will transition to completely redesigned Datatracker database schema. The new schema will better support today's needs, and we believe it will better support future enhancements. Frankly, we outgrew the old schema some time ago. In order to achieve a nearly unnoticeable change-over, we now invite you to try out the new Datatracker, bang on it, kick the tires, and generally see if it works as well for you as the old one. For some additional insight, you may want to read the instructions that was given to our testers: http://trac.tools.ietf.org/tools/ietfdb/wiki/InstructionsForTesters Or, you may want to just jump in and see how it works. Either way, please report any bugs, problems, surprises, gremlins, hiccups, flaws, and so on that you discover. Reports will receive prompt attention. We deploy new code upgrades (if any are available) every hour. Please use this mail list to report issues: iola-conversion-t...@ietf.org Try out the new Datatracker, and help us make a smooth transition. The new Datatracker is running here: https://trackerbeta.ietf.org/ Thank you for your assistance, Russ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-core-link-format-11.txt (CoRE Link Format) to Proposed Standard
The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'CoRE Link Format' draft-ietf-core-link-format-11.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 i...@ietf.org mailing lists by 2012-02-28. 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 This document defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header format defined in RFC5988, the CoRE Link Format is carried as a payload and is assigned an Internet media type. A well- known URI is defined as a default entry-point for requesting the links hosted by a server. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-core-link-format/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-core-link-format/ 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
Reminder: T-shirt Design Contest for IETF 83
This is a reminder that the IAOC is conducting a T-Shirt Design Contest to develop a unique t-shirt for the Paris meeting. You have until this Friday, Feb 17 to submit your design for consideration. We've received two submissions so far and you can see them here: http://www.ietf.org/meeting/83/t-shirt-design-contest-submissions.html. If you have design skills, or can strongarm someone else who does, please view this as an opportunity to show your support for the IETF. The Secretariat will take care of producing the shirts once the winning design is selected, and the purchase price (approximately $25 USD) will go to support the IETF. Whoever submits the winning design will receive a free t-shirt. Please send your design to tshirtcont...@ietf.org. Designs should be delivered as EPS or Adobe Illustrator files. A t-shirt template is available for download here: ietf.org/meeting/83/t-shirt-contest-template.eps. Your submission should include t-shirt color, and the design for both front and back of the shirt. Please note: designs should include the IETF logo, but cannot include any company logos. Like an Internet-Draft, a t-shirt design submission is authored by individuals. Regards, Alexa -- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Recharter of Locator/ID Separation Protocol (lisp)
A modified charter has been submitted for the Locator/ID Separation Protocol (lisp) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Thursday, March 1, 2011. Locator/ID Separation Protocol (lisp) - Current Status: Active Last updated: 2012-02-14 Chairs: Joel Halpern j...@joelhalpern.com Terry Manderson terry.mander...@icann.org Internet Area Directors: Ralph Droms rdroms.i...@gmail.com Jari Arkko jari.ar...@piuha.net Internet Area Advisor: Jari Arkko jari.ar...@piuha.net Secretaries: Wassim Haddad wassim.had...@ericsson.com Luigi Iannone lu...@net.t-labs.tu-berlin.de Mailing Lists: General Discussion: l...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the locator/identifier separation. The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The LISP WG is chartered to continue work on the LISP base protocol, completing the ongoing work, and any items which directly impact LISP protocol structures and which are related to using LISP for improving Internet routing scalability. Specifically, the group will work on: - Architecture description: This document will describe the architecture of the entire LISP system, making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. - Deployment models: This document will describe what kind of deployments can be expected for LISP, and give operational advice on how they can be set up. - A description of the impacts of LISP: This document will describe the problems that LISP is intended to address and the impacts that employing LISP has. While the work on LISP was initiated by Internet routing scaling concerns, there has also been an interest on improved solutions to a number of different problems, such as traffic engineering. This document should describe problem areas (such as scaling or traffic engineer) where LISP is expected to have a positive effect, as well as any tradeoffs that are caused by LISP's design. - LISP security threats and solutions: This document will describe the security analysis of the LISP system, what issues it needs to protect against, and a solution that helps defend against those issues. The replay attack problem discussed on the mailing list should be included in this work. - Allocation of Endpoint IDentifier (EID) space: This document requests address space to be used for the LISP experiment as identifier space - Alternate mapping system designs: Develop alternative mapping designs to be tested. - Data models for management of LISP. The first three items need to be completed first before other items can be submitted as RFCs. The three first documents also need to complement each other, by describing how the architecture supports a solution for a particular problem area and how the solution can be deployed to help with that problem. In addition, if work chartered in some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. It is expected that the results of specifying, implementing, and
Last Call: draft-ietf-adslmib-gbond-mib-09.txt (xDSL multi-pair bonding (G.Bond) MIB) to Proposed Standard
The IESG has received a request from the ADSL MIB WG (adslmib) to consider the following document: - 'xDSL multi-pair bonding (G.Bond) MIB' draft-ietf-adslmib-gbond-mib-09.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 i...@ietf.org mailing lists by 2012-02-28. 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 This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-mib/ 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
Last Call: draft-ietf-adslmib-gbond-atm-mib-05.txt (ATM-Based xDSL Bonded Interfaces MIB) to Proposed Standard
The IESG has received a request from the ADSL MIB WG (adslmib) to consider the following document: - 'ATM-Based xDSL Bonded Interfaces MIB' draft-ietf-adslmib-gbond-atm-mib-05.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 i...@ietf.org mailing lists by 2012-02-28. 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 This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based networks. This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.1. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-atm-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-atm-mib/ 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
Last Call: draft-ietf-adslmib-gbond-tdim-mib-07.txt (xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB) to Proposed Standard
The IESG has received a request from the ADSL MIB WG (adslmib) to consider the following document: - 'xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB' draft-ietf-adslmib-gbond-tdim-mib-07.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 i...@ietf.org mailing lists by 2012-02-28. 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 This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), defined in ITU-T recommendation G.998.3. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-tdim-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-tdim-mib/ 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
Last Call: draft-ietf-adslmib-gbond-eth-mib-05.txt (Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB) to Proposed Standard
The IESG has received a request from the ADSL MIB WG (adslmib) to consider the following document: - 'Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB' draft-ietf-adslmib-gbond-eth-mib-05.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 i...@ietf.org mailing lists by 2012-02-28. 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 This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.2. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-eth-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-eth-mib/ 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
