[Int-area] New version of shared addressing I-D (RE: WGLC for draft-ietf-intarea-shared-addressing-issues-01)
Dear chairs, WG members, The LC for this I-D ended yesterday. A new version has been edited taking into account the comments received so far; in particular: 1. Comments from Brian: http://www.ietf.org/mail-archive/web/ int-area/current/msg02356.html. A note on session failure due to NAT overflow has been added. The proposed wording for the security section has been also accepted. 2. Comments from Wes: http://www.ietf.org/mail-archive/web/int-area/ current/msg02357.html. To handle the comments from Wes, a new section (MTU) has been introduced. Wes has kindly provided text for this section. Thanks! 3. Offline comments received from Dan Wing. Dan made some suggestions to enhance the readability of the Traceability Section. Most of Dan's proposal have been accepted. Many thanks for the reviewers and for their effort to enhance this document. The new version is available at: https://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issues/ A diff file can be found at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-intarea-shared-addressing-issues-02 Both xml and txt files have been uploaded. Chairs, what is the next step? Cheers, Med -Message d'origine- De : int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] De la part de Laganier, Julien Envoyé : jeudi 30 septembre 2010 21:24 À : int-area@ietf.org Cc : draft-ietf-intarea-shared-addressing-iss...@tools.ietf.org; Christian Vogt Objet : [Int-area] WGLC for draft-ietf-intarea-shared-addressing-issues-01 Folks, This note initiates a two weeks WG Last Call for http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-01 Please review the draft and send your comments to the mailing list before 2010-10-14 COB PST. Please also state whether or not you think the draft is ready to be forwarded to IESG for publication as an Informational RFC. Thank you for your support. --julien christian ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area * This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
On 05/10/2010 08:04 p.m., Joel Jaeggli wrote: It is much worse. At the IP and Transport level functionality, the IPv4 Internet is essentially frozen somewhere in the 1990's. Sad... Now is not the point to invest time fixing the ipv4 internet. Unless you expect that it will be *replaced* in 5 years or so with something else, I'd argue Why not?. There are estimates of 15-20 more years of living with IPv4, so Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
On 10/15/10 10:33 AM, Fernando Gont wrote: On 05/10/2010 08:04 p.m., Joel Jaeggli wrote: It is much worse. At the IP and Transport level functionality, the IPv4 Internet is essentially frozen somewhere in the 1990's. Sad... Now is not the point to invest time fixing the ipv4 internet. Unless you expect that it will be *replaced* in 5 years or so with something else, I'd argue Why not?. because the software and stack have already osified. existing systems are not going to pick up changes that you implement particularly in the waist of the hourglass. That's just reality. There are estimates of 15-20 more years of living with IPv4, so you're going to have 20 years of supporting the assumptions currently present in legacy systems. Thanks, ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
From: Joel Jaeggli joe...@bogus.com because the software and stack have already osified. The implication being that that's not true for IPv6? That will please the ILNP people to hear, I'm sure, what with ILNP being the official RRG recommendation for multi-homing support (now that MULTI6 has been turned down by the users) - since ILNP requires changes to the host stacks (in the IPv6 and TCPv6 code). So how well you do think that change will be accepted by the v6 host community? Noel ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]
On 10/15/10 11:44 AM, Noel Chiappa wrote: From: Joel Jaeggli joe...@bogus.com because the software and stack have already osified. The implication being that that's not true for IPv6? However painful it may be, altering the stacks of devices not yet built is easier than that of those already in the field. That will please the ILNP people to hear, I'm sure, what with ILNP being the official RRG recommendation for multi-homing support (now that MULTI6 has been turned down by the users) - since ILNP requires changes to the host stacks (in the IPv6 and TCPv6 code). So how well you do think that change will be accepted by the v6 host community? I believe the word you're looking for is recalcitrant. Noel ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
