Introducing draft-denog-v6ops-addresspartnaming

Joel Jaeggli joelja at bogus.com
Sun Nov 21 23:57:55 UTC 2010


On 11/21/10 2:50 PM, William Herrin wrote:
> On Sun, Nov 21, 2010 at 11:40 AM, Joel Jaeggli <joelja at bogus.com> wrote:
>> There is a lot of assumption on the part of ipv6 that the use of ipv6
>> literals in uri's would be a rather infrequent occurrence, given how
>> infrequent it is in ipv4 it would seem to be a reasonable assumption.
> 
> Joel,
> 
> Looks like an ass-u-me. If you think the use if IPv4 addresses in URLs
> is infrequent, it's mostly "u." Get out in the field some time.

In the situation where, load balancers, virtual hosting and named ssl
certs are the lingua franca, ip4 literals  have rather limited usable
scope. there have been a couple of studies associated with thinking
about protcol translation, which if they're not totally off-base in fact
conclude their usage in public services is rather rare.

if you really want to type something like:

http://[2001:490:f000:16:20c:29ff:fe95:c05d]:8080

to reach a freshly provisioned host, I don't think adding the brackets
is the bulk of the effort and I kinda doubt google is going to help you
complete it.

> I've yet to work for a non-ISP that (before I arrived) maintained
> their internal DNS consistently vice using address literals. If the
> company was small, they didn't really know how to operate a DNS
> server. If large, the DNS ops were too inaccessible to be consulted on
> things that weren't also being reviewed by PR for release to the
> general public.

I am aware of locations where the operation of the DNS is not a source
of competitive advantage, I may in fact work in one, that said without
it you're going to be in more hurt than in ipv4.

> In fact, in one project I occasionally work on, the team is
> -frequently- told by the DNS op for the NIPR-based DNS server how
> bothered he is by the lookup count, so won't we please place commonly
> used Internet names in our /etc/hosts. My jaw dropped the first time I
> heard that one.
> 
> That server op is the kind of guy we're asking to understand that
> there's nothing special about the two bytes between the colons in the
> IPv6 address. He's gonna be trouble.
>
> 
> On Sun, Nov 21, 2010 at 1:42 PM,  <Valdis.Kletnieks at vt.edu> wrote:
>> On Sat, 20 Nov 2010 12:12:09 EST, William Herrin said:
>>> 260:abcde:123456:98::1
>>>
>>> 260 - IANA to ARIN, a /12
>>> abcde - ARIN to ISP, a /32
>>> 123456 - ISP to customer, a /56
>>> 98 - customer subnet
>>> ::1 - LAN address
>>
>> What do you do when ARIN gives Tier1 a /24, and Tier1 gives Billy Bob's
>> Bait, Tackle, and Internet a /40, and Billy Bob gives one of their customers a /56?
> 
> Whatever you want to do. That's the point of optional/movable separators.
> 
> An option w/ movable separators:
> 
> 260:abc:1234:9876:fe::1
> 
> Actual IPv6 standard (and also allowed w/ movable separators):
> 
> 260a:bc12:3498:76fe::1
> 
> 
> On Sun, Nov 21, 2010 at 5:15 PM, Owen DeLong <owen at delong.com> wrote:
>>> Imea nrea lly, what ifwe wrot eEng lish thew aywe writ eIPv 6add ress
>>> es? Looks pretty stupid without a floating separator, doesn't it?
>>>
>> If this were prose, sure. It isn't. It's an addressing scheme. I mean,
>> really, we don't question 99999-1520 or 408-555-1212 which
>> are much more like what we're talking about.
>>
>> In fact, it would look pretty weird to most people if we started writing
>> 951-21-42-33 (or I bet they wouldn't expect that was a zip code in
>> any case). Similarly, if we start placing the separators in arbitrary
>> places in phone numbers, people get confused.
> 
> That would be a more compelling argument if it accurately described
> phone number notation. It doesn't. "+44 121 410 5228," for example, is
> the phone number for parking services at Heathrow airport, exactly as
> described on http://www.heathrowairport.com/'s "contact us" page. No
> dashes at all, and not 10 digits.
> 
> And BTW, 408-555-1212 isn't arbitrarily separated. Each component has
> a specific meaning. Long distance region 408, telco reserved prefix
> 555, long distance information 1212.
> 
> The Zip code's components also have meaning. The left 5 digits
> indicate the specific post office and the right 4 digits usually
> specify the internal box number used for sorting the mail.
> 
> Even IPv4's dot separators were placed in meaningful locations in the
> original Classful design. The network address was always the whole
> content to the left of one of the dots while the host address was
> always the whole content to the right. Unless the network was complex
> enough to have a subnet address in the middle, still confined by the
> dots. It's an anachronism now, but the separators were originally
> important.
> 
> IPv6 is one of very few addressing schemes in which the separators
> intentionally have no greater meaning within the protocol or its use.
> They're just there. If we want folks to understand that difference
> from their normal experience with addressing notations, we'll have to
> call attention to it by, for example, leaving the byte groupings
> formally unnamed.
> 
> 
> 
>>>> Dash is a poor choice because it becomes potentially problematic
>>>> to know whether your cisco is telling you that:
>>>> 2001-0db8-5f03 is a MAC address or a /48 prefix.
>>>
>>> Cisco's expression of a MAC address is wrong anyway. Correct notation
>>> for a MAC address is separating each byte with a colon.
>>>
>> Doesn't matter... It's widespread and Cisco isn't the only one to use it.
> 
> Just for my own edification, who else besides Cisco do you know who
> uses that notation for MAC addresses? I want some convincing before
> I'll accept the claim that it's widespread.
> 
> -Bill
> 
> 
> 
> 





More information about the NANOG mailing list