Brocade, or at least the Foundry part of Brocade.
Nick
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.
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 Heathrow: Welcome to Heathrow Airport | Heathrow "contact us" page. No
dashes at all, and not 10 digits.
Sure, but, try presenting a NANPA phone number in that format to just about
anyone in the US and you'll get a pretty perplexed look. In fact, many people
have a great deal of difficulty when confronted with +1 408 555 1212, let
alone something like +1 40 85 55 12 12 or any other derivitave you might
want to come up with.
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.
Which is why I offered 951-21-42-33 as an alternative... Turns
out that has significance too... 951 is the bulk mail center. 21 is
the post office within the bulk mail center service area. 42
is the carrier route and 33 is of local significance within the
route. Most post offices have two zip codes... The second one
is usually the standard zip++ and is used for po boxes where
the format is BBBpX-XXXX whiere BBB is still the builk mail
center, but, X-XXXX is the P.O. Box.
We could also move on to SSNs which would confuse people
no end if you wrote them as 57523-1234 rather than as 575-23-1234.
In fact, you could have lots of fun writing zip codes as 951-21-4223
and SSNs as 57523-1234.
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.
I don't think leaving the hextets unnamed helps with that in any meaningful
way.
As I said, the only thing you accomplish by leaving it formally unnamed
is to cause everyone to make up their own local name and expand the
confusion.
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.
Cisco alone is a sufficient sample of the market to constitute widespread
usage. However, several router vendors that have cloned Cisco behaviors
and command-line syntax have also cloned this mess.
I don't recall their names for certain off the top of my head, but, I know I've
encountered it on non-Cisco routers.
Owen
You seem to be indirectly answering the parent posting in much of what
you say. That is fine, I just wanted to point it out.
> It's a commonly accepted, well-defined convention to save humans
> effort while not sacrificing readability. There are weirder things in
> technology.I don't think it's all that weird and it's a major savings in writing
out IPv6 addresses and being able to read them (except in lists of
varying sized addresses (please, when dumping routing tables
and such, just keep the optional zeroes or give us a flag to choose).
In practice, the :: usually ends up being placed between the
network number and the host number for things with static
addresses and rarely appears in EUI-64 based addresses,
so, I don't see this as a problem.
FWIW, I do not see it as weird or as a problem, either. "There are
weirder things" does not mean the thing I am referring to is weird
itself 
I don't see a problem with people not assigning customers /56s so long
as they go in the correct direction and give /48s and not /60s or /64s.
Many ISPs will end up handing their customers /64, /62 or other
less-than-ideal prefixes. As soon as a customer needs to subnet their
/64, the real fun starts. There is nothing we can do about it, other
than trying to educated people and hope for the best.
> I honestly think I never explained (as in, after I understood the
> matter, myself) netmasks other than as a bit vector. Unless you mean
> "write 255.255.255.0 in there cause that's what right for you".Then you are young and never had to deal with systems that didn't
know about bit-vector syntax. I have had to explain the translation
between bit-vector syntax (/n) and bit-field syntax (255.255.255.240)
to many people. It's easy when n is a multiple of 8. After that,
it can be quite hard for some mathematically challenged individuals
unfamiliar with binary and BCD to wrap their heads around.
I wish 
Either the person can grasp that a dotted netmask can be transformed
into a bit vector or I tell them "use 255.255.255.0 everywhere, it
will work for everything you will ever need." 80/20 and all that.
Removing bitmath from operations where possible is a good thing
that reduces outages caused by human factors. It's just good human
factors engineering.
We can't do so in IPv4, there aren't enough bits to do it.
We seek to do so in IPv6 with ARIN draft policy 2010-8 and
proposal 121.
If by bitmath you mean ending netmasks not on full bytes only, I could
not agree more. This will reduce a lot of useless overhead.
I really wish the RIRs would get unique a name space for their
respective drafts. If even my person object needs a -RIPE suffix, I
don't see why drafts etc don't.
Should we all sing kumbayah now?
Only if you bring a tambourine.
Basically, as I recall the earlier discussions of this and the IETF
arriving at the decision to use colon (:), it boiled down to the
simple fact that colon (
Agreed.
Richard
Because in my version fd::/8
actually is the same as fd00::/8, which, as you rightly point out, is
exactly what a normal human being would naturally expect.
Which is against every expectation of anyone who ever learned Arabic
numbers in a left-to-right system. As Owen pointed out, filling with
zeros on the right-hand side would be, to put it lightly, a disaster.
Maybe I should have worded that more strongly in my last reply.
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?
Reductio ad absurdum.
We've gone too far down the wrong path to change it now; colons are
going to separate every second byte in the v6 address. But from a
human factors perspective, floating colons would have been better.
No. See my, and Owen's, emails.
From a computer parser perspective, a character other than a colon
would have been better because colons are already claimed for many for
other syntax elements that include an IP address, like the
address/port separator in a URL.
It's the least bad amongst a highly limited choice of even worse
chars. There is a reason why the colon is used so often.
Making the jump in logic, it would help mitigate the errant design if
the two-byte groupings separated by the colons were intentionally and
formally not named. That fits a training scenario which reinforces the
idea that the colons are there for convenience but that there is
nothing special about those two byte groupings.
Personally, I have no interest whatsoever in limiting my efficiency
and increasing the chance that I or others make mistakes because
people who don't understand the matter at hand might misinterpret
something.
The question leads me to recall a fancy version of traceroute I once
used. In addition to looking up the PTR record for each hop, it also
looked up the org and AS number currently associated. If users found
it valuable to have the router present variable colon placement, it's
a doable albeit complex computing task.
If you ever looked at the state of a lot of data in the RIR's whois
databases, you know that's literally impossible. And a _lot_ of effort
for little to no gain. And what if a LIR changes their numbering
scheme, at some point? Attach parsing instructions to inetnum?
Richard
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.
The complete uniformity of telephone numbers seems to be a North
American phenomena, but as a German who is used to wildly different
phone numbers, I would still prefer a common scheme for all of them,
yes.
I still disagree. While I noted the one pathology with the current
system, that same pathology is present with floating colons
and there are others which I also pointed out (difficulty in
reproducing the "correct" placement of the floating colons in
automated output, for example.
Even worse, allowing floating colons will mean different groups will
adapt different defaults. Not a desirable goal.
The syntax for handling this was already present in IPv4 and is easily
adapted to the problem in IPv6. Simply wrap the IPv6 address in
square brackets (e.g. [2001:db8:feed::cafe]:80 is the ipv6
address 2001:db8:feed::cafe on port 80).
Which is admittedly ugly, but I can't think of anything better, either.
We did forego ::192.168.1.1. However, we still have ::ffff:192.168.1.1
and for good reason. This is a useful construct for allowing humans
to see in log files that an IPv6-aware application on a dual-stack
machine accepted an IPv4 connection on an IPv6 socket.
Agreed. Ugly, but useful & needed.
Richard
Please don't group several emails into one. It breaks threads. And
while I could not find anything about this in the NANOG FAQ, it's
common netiquette not to do so.
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.
Ad hominem usually does not do much to maintain or improve the quality
of a discussion.
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.
As you described yourself, he is gonna be trouble anyway. People end
up working around him anyway, so why bother to cater to his needs?
Especially as the fixed colons are here to stay and a good thing,
also.
Whatever you want to do. That's the point of optional/movable separators.
Principle of least surprise.
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 Heathrow: Welcome to Heathrow Airport | Heathrow "contact us" page. No
dashes at all, and not 10 digits.
The UK is not part of the USA nor of Canada.
IPv6 is one of very few addressing schemes in which the separators
intentionally have no greater meaning within the protocol or its use.
As has been pointed out several times before, helping humans reduce
errors is a highly desirable goal. _And_ the discussion is moot
anyway. I think I am at a point where I will simply ignore any new
occurrences of this theme.
Richard
[ Meant to send this to the list and not directly to Richard. ]
For the sake of completeness, the relevant part of what I answered
privately can be found below.
Because in my version fd::/8
actually is the same as fd00::/8, which, as you rightly point out, is
exactly what a normal human being would naturally expect.Which is against every expectation of anyone who ever learned Arabic
numbers in a left-to-right system. As Owen pointed out, filling with
zeros on the right-hand side would be, to put it lightly, a disaster.
Maybe I should have worded that more strongly in my last reply.
Richard,
A route prefix is always trimmed on the right. Always. That's why we
call it a "PREfix."
Trimming zeros on both the left and the right, as the correctly
written IPv6 notation "1::/16" would have us do, is confusing. It's
like writing one million and one tenth as "1,.1" instead of
"1,000,000.1".
Please don't group several emails into one. It breaks threads. And
while I could not find anything about this in the NANOG FAQ, it's
common netiquette not to do so.
Six of one, half a dozen of the other. Flooding a list with half a
dozen replies on the same thread at the same time is poor netiquette
for its impact on unthreaded mail agents and if your mailer started a
new thread for this message in spite of the identical subject and
in-reply-to header then it's broken.
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.Ad hominem usually does not do much to maintain or improve the quality
of a discussion.
Insolence alone does not rise to argumentum ad hominem. "The predicate
assumption is wrong. Here's several paragraphs about what's actually
observed in the field," certainly isn't. If you want to call me out on
a logical fallacy, at least call me out on one I've actually
committed.
Regards,
Bill Herrin
I don't see a problem with people not assigning customers /56s so long
as they go in the correct direction and give /48s and not /60s or /64s.Many ISPs will end up handing their customers /64, /62 or other
less-than-ideal prefixes. As soon as a customer needs to subnet their
/64, the real fun starts. There is nothing we can do about it, other
than trying to educated people and hope for the best.
If we educate a sufficient percentage of ISPs and solve the perception
problems of the RIR policies that are driving some ISPs to be overly
conservative (see proposal 121 in the ARIN region for an example of
what I think represents a reasonable solution), then, the other ISPs
will eventually find themselves at a competitive disadvantage as their
customers start to ask "Why can't I have a /48 like my friend Bob
got from provider Z?" This is a good thing, but, it means we need to
do what we can to educate as many ISPs as possible as quickly
as possible during this critical phase of deployment.
I honestly think I never explained (as in, after I understood the
matter, myself) netmasks other than as a bit vector. Unless you mean
"write 255.255.255.0 in there cause that's what right for you".Then you are young and never had to deal with systems that didn't
know about bit-vector syntax. I have had to explain the translation
between bit-vector syntax (/n) and bit-field syntax (255.255.255.240)
to many people. It's easy when n is a multiple of 8. After that,
it can be quite hard for some mathematically challenged individuals
unfamiliar with binary and BCD to wrap their heads around.I wish
Either the person can grasp that a dotted netmask can be transformed
into a bit vector or I tell them "use 255.255.255.0 everywhere, it
will work for everything you will ever need." 80/20 and all that.
Ah... OK... Sorry, I'm the guy that had to deal with all of your users
when they found themselves on one of my /27s and tried to use
255.255.255.0 there. 
So... Don't worry, I ended up picking up the educational task where
you left off.
(OK, maybe not the exact same set of users, but, honest, you're not
the only one who took this approach and it did lead to interesting
breakages by users so educated in a number of places I have worked.)
Removing bitmath from operations where possible is a good thing
that reduces outages caused by human factors. It's just good human
factors engineering.
We can't do so in IPv4, there aren't enough bits to do it.
We seek to do so in IPv6 with ARIN draft policy 2010-8 and
proposal 121.If by bitmath you mean ending netmasks not on full bytes only, I could
not agree more. This will reduce a lot of useless overhead.
I really wish the RIRs would get unique a name space for their
respective drafts. If even my person object needs a -RIPE suffix, I
don't see why drafts etc don't.
Well, in IPv6, I think ending them on nibbles is fine. Specifically, see
ARIN Policy Proposal 121 (as mentioned above).
Should we all sing kumbayah now?
Only if you bring a tambourine.
LoL
Sorry, I don't own a tambourine.
Owen
Trimming zeros on both the left and the right, as the correctly
written IPv6 notation "1::/16" would have us do, is confusing. It's
like writing one million and one tenth as "1,.1" instead of
"1,000,000.1".
No, there are simply two mechanisms at work:
I start with
0001:0000:0000:0000:0000:0000:0000:0000/16
then, I remove leading zeros as they are not needed
1:0000:0000:0000:0000:0000:0000:0000/16
which I can further reduce by the same mechanism to
1:0:0:0:0:0:0/16
Finally, the accepted convention for IPv6 addresses is that I can drop
a continuous block of zeros which means I end up with
1::/16
Makes perfect sense to me.
Six of one, half a dozen of the other. Flooding a list with half a
dozen replies on the same thread at the same time is poor netiquette
for its impact on unthreaded mail agents and if your mailer started a
new thread for this message in spite of the identical subject and
in-reply-to header then it's broken.
I disagree, but if you want to continue this part of the discussion,
we should do so off-list. I do apologize that I wrote this in-line and
did not poke you off-list in the first place.
Insolence alone does not rise to argumentum ad hominem. "The predicate
assumption is wrong. Here's several paragraphs about what's actually
observed in the field," certainly isn't. If you want to call me out on
a logical fallacy, at least call me out on one I've actually
committed.
I called out a social, not a logical, fallacy. As per the rest, see above.
Richard
Richard Hartmann <richih.mailinglist@gmail.com> writes:
I will add quad to -03 anyway. If you get a few +1 on hexquad, I am
against adding that, as well.
Quad is a standard term for "64 bit integer" in C/C++. For
example:
$ grep -c quad /usr/src/sys/netinet6/*|awk -F: '{tot+=$2} END{print tot}'
171
which is to say, the kame derived ipv6 stack on this machine uses
one of the *quad_t types 171 times.
Ambiguating usages like "Take the least signifigant quad of that
ipv6 address" to mean either 16 bits or 64 bits, when it currently is
unamibigously 64 bits won't make the lives of C/C++ programmers
writing IPv6 code any easier.
Given that a meal is often comprised of several mouthfuls, wouldn't it
stand to reason that the entire address would suffice there? 
Scott
then, the other ISPs
will eventually find themselves at a competitive disadvantage as their
customers start to ask "Why can't I have a /48 like my friend Bob
got from provider Z?"
I kinda implied that, but yes, I should have written it out. Thanks
So... Don't worry, I ended up picking up the educational task where
you left off.
Even though this is getting kinda off topic:
In my private life, I either explain what a bit vector is or I tell
them to use a /24.
In my professional life, I either deal with people who can grasp the
bit vector thing or they bought the complete care package anyway,
meaning that we tell them where to click on the CMS to make the
colourful overload they call a website go bling. In the latter case, I
don't have to explain anything because
a) that part is handled by someone else
b) they have no interest whatsoever in learning what an IP address is,
let alone a netmask.
(OK, maybe not the exact same set of users, but, honest, you're not
the only one who took this approach and it did lead to interesting
breakages by users so educated in a number of places I have worked.)
The question is: Would those users have acted any differently if
someone went to the trouble of explaining in depth what they would
have forgotten within days?
Well, in IPv6, I think ending them on nibbles is fine.
Hmm, true. That's fine, too.
Richard
Agreed.
Thanks a lot for pointing this out. Comments like this are incredibly
valuable to me. I think I will still add quad to -03 as it has been
requested a lot of times, but more to point out and document that
there is a significant problem with it than anything else.
Thanks again,
Richard
I thought the Jargon File settled that long ago: 4 bits = nybble, 8 bits = byte, 16 bits = playte, 32-bits = dynner. See http://dictionary.die.net/nybble
Since the zeros between double colons are indefinite length, call it the voyd and be done.
Erm. Belated, but I am _not_ against adding etc pp.
Richard
If we can't choose mouthful (which for some reason sounds thematically
correct), "chunk" gets my vote.
*(Chunk = Maybe not the most technical, but has been working for me all
along ...)*
/TJ
If we can't choose mouthful (which for some reason sounds thematically
correct), "chunk" gets my vote.
*(Chunk = Maybe not the most technical, but has been working for me all
along ...)*
Chunk is at least the proper English term for these bits between the
colons. The process of breaking up a long string into shorter
substrings is already known as "chunking". With IPv4, the chunking was
done on octet boundaries so people used the specific term "octet"
instead of the more general "chunk". But in the absence of a specific
term, chunk is the correct and proper way to refer to these bits.
IPv6 addresses are chunked into 16 bit chunks and each chunk is
written down in hexadecimal notation with a colon between the chunks.
For example, 805B:2D9D:DC28:0000:0000:FC57:D4C8:1FFF. Of course there
are some other rules that allow for shorter strings but they all start
with the 8 chunks separated by colons. The last 4 chunks represent the
interface identifier and the first 4 chunks are the network prefix.
-- Michael Dillon