Re: Variable length internet addresses in TCP/IP: history

G'day. Always fun to watch an exchange among entrenched perspectives... On 2/14/2012 9:31 AM, Bob Braden wrote: 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

Auth48 comments on draft-ietf-pwe3-static-pw-status-10

During Auth 48, the authors of draft-ietf-pwe3-static-pw-status found some issues with the acknowledgement procedures in Section 5.3 of the draft that we feel should be addressed before publication. Since the draft has already been through WG and IETF last call, we would like to highlight the pr

Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC

To be more specific, at least section 5.5 ("it is unclear how implementers will judge when the network conditions will have changed sufficiently to justify turning off DNS Resolver Whitelisting and/or what the process and timing will be for discontinuing this practice") is now incorrect. It *is*

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP'

I fully support this draft and would like to see it progress to conclusion without further delay. With warm regard, Kirk Erichsen Principle Technology Engineer Time Warner Cable ATG West This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is pri

Re: Another last call for draft-weil

+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: A

Followup Gen-ART Review on draft-ietf-dhc-forcerenew-nonce

Hi, This is a followup on my Gen-ART review of draft-ietf-dhc-forcerenew-nonce-04, based on my previous review of version 03. In summary, this version is improved, but I still don't think it's ready for publication. On Feb 6, 2012, at 5:17 PM, Ben Campbell wrote: > I am the assigned Gen-ART r

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

I'm agnostic about the latest round of changes or not. I just want EITHER version to move forward soon! Owen On Feb 14, 2012, at 10:38 AM, Pete Resnick wrote: > 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

Re: Another last call for draft-weil

I agree. This needs to be published by the IETF as an RFC. the current form is quite suitable for that. Yours, Joel On 2/14/2012 1:28 PM, Scott O Bradner wrote: +1 On Feb 14, 2012, at 1:25 PM, Ross Callon wrote: +1. Ross *From:*ietf-boun...@ietf.org [mailto:ie

Re: Variable length internet addresses in TCP/IP: history

> From: Bob Braden > You probably remember this, but... I was on the very edge at the time (more below), but yes. A few things that caught my eye (including a minor date offset - I like to get noise out of the record before it gets engrained): > argued strenuously for variable leng

Re: Variable length internet addresses in TCP/IP: history

On Wed, 2012-02-15 at 13:23 -0500, Noel Chiappa wrote: > The sad part is that we could have had our cake, and eaten it too! If a (hierarchical) variable length addressing would not have mandated a hierarchical routing as well, then yeah, cake would have tasted well as it remained there on the tab

Re: Last Call: (Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6)) to Informational RFC

I'd like to support this draft, having reviewed it carefully. Shim6 is running code whose time will come, and this document is useful background for implementation and deployment. Regards Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www

Re: Backwards compatibility myth [Re: Last Call: ]

> From: j...@mercury.lcs.mit.edu (Noel Chiappa) > Ironically, TCP/IP had variable length addresses put in _twice_, and > they were removed both times! Sigh, another correction for the record: it was _three_ times!!! Early versions of IPv4 (IEN-28, confusingly titled "Draft Internetwor

Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space)

I support this draft as updated. William Hale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call:

support ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: Variable length internet addresses in TCP/IP: history

On 15-Feb-12 08:42, Dave CROCKER wrote: > As I recall, there was essentially no experience with variable length > addresses -- and certainly no production experience -- then or even by > the early 90s, when essentially the same decision was made and for > essentially the same reason.[1] > > It's no

Re: WG Review: Recharter of Locator/ID Separation Protocol (lisp)

A WG Review message for this WG already went out a month ago. What has changed to necessitate another Last Call? Could the-powers-that-be please make it easier for those who might care to understand if there is something here that we should know and possibly comment about? A simple explanation,

Re: Variable length internet addresses in TCP/IP: history

On 2/15/2012 1:10 PM, Stephen Sprunk wrote: The problem with variable-length addressing that, in practice, one needs to specify a maximum length. In some practical terms, perhaps, but there are extensibility schemes that allow the payload (addressing bits, in this case, to go on forever, in

Re: Variable length internet addresses in TCP/IP: history

This is essentially correct. The apparent conceptual difference is that a variable length address looks more like source routing. The end system owns only a small part of the total address; the rest is the network portion, fashioned to seem like a source route. Depending on how the address is

Re: Variable length internet addresses in TCP/IP: history

>> The problem with variable-length addressing that, in practice, one needs >> to specify a maximum length. > > In some practical terms, perhaps, but there are extensibility schemes that > allow the payload (addressing bits, in this case, to go on forever, in > theoretical terms. I look forward

Re: Variable length internet addresses in TCP/IP: history

>> The problem with variable-length addressing that, in practice, one needs >> to specify a maximum length. > > In some practical terms, perhaps, but there are extensibility schemes that > allow > the payload (addressing bits, in this case, to go on forever, in theoretical > terms. One example w

Re: Variable length internet addresses in TCP/IP: history

On 2/15/2012 1:39 PM, Richard Barnes wrote: The problem with variable-length addressing that, in practice, one needs to specify a maximum length. In some practical terms, perhaps, but there are extensibility schemes that allow the payload (addressing bits, in this case, to go on forever, in

Re: Variable length internet addresses in TCP/IP: history

> From: Steve Crocker > a variable length address looks more like source routing. > ... > the network portion, fashioned to seem like a source route. > ... the division of the network portion into routing steps will be > specified in advance or will be interpreted at each

Re: Variable length internet addresses in TCP/IP: history

Scott, if memory serves you and I wanted the high-order 2 bits of the IPng address to select between 64, 128, 192, and 256-bit addresses -- and when we couldn't get that we got folks to agree on 128-bit addresses instead of 64-bit, which is what had been on the table. On Feb 14, 2012, at 1:37 39PM

RE: Variable length internet addresses in TCP/IP: history

But the maximum for implementation is not necessarily the maximum for the packet format. Thus one could have started with a variable length address format, but said "For the immediate future we will always pick a length of 32 bits". Then at some point we could have said "in 5 years we are goin

Re: Variable length internet addresses in TCP/IP: history

On Feb 15, 2012, at 5:44 53PM, Ross Callon wrote: > But the maximum for implementation is not necessarily the maximum for the > packet format. > > Thus one could have started with a variable length address format, but said > "For the immediate future we will always pick a length of 32 bits".

Re: Variable length internet addresses in TCP/IP: history

Steve Crocker wrote: > The only way variable length address would have provided a > smooth transition is if there had been room to increase the > length of the address after some years of use. Bottom up approach to extend address length toward port numbers, thus, worked, is working and will keep

Re: Variable length internet addresses in TCP/IP: history

Steven Bellovin wrote: > Scott, if memory serves you and I wanted the high-order 2 bits of the IPng > address to select between 64, 128, 192, and 256-bit addresses -- and when > we couldn't get that we got folks to agree on 128-bit addresses instead of > 64-bit, which is what had been on the table

Re: Variable length internet addresses in TCP/IP: history

On Feb 15, 2012, at 7:43 30PM, Masataka Ohta wrote: > Steven Bellovin wrote: > >> Scott, if memory serves you and I wanted the high-order 2 bits of the IPng >> address to select between 64, 128, 192, and 256-bit addresses -- and when >> we couldn't get that we got folks to agree on 128-bit addre