Introducing draft-denog-v6ops-addresspartnaming
Hi all, as most of you are aware, there is no definite, canonical name for the two bytes of IPv6 addresses between colons. This forces people to use a description like I just did instead of a single, specific term. Being highly pedantic Germans, this annoyed quite a few people within the DENOG community. This, in turn, lead to an I-D[1]. If any of you have any additional suggestions, you are more than welcome to share them. Additionally, I want to invite everyone to participate in an informal poll which we created[2]. We're fully aware that it's trivial to cheat on this poll; that's life. As of right now, Quibble leads with Hextet being a close second. All other options got significantly less votes. Thanks, Richard [1] http://tools.ietf.org/html/draft-denog-v6ops-addresspartnaming [2] http://doodle.com/5q9gfvk4qe6zmzc6
Hi all,
as most of you are aware, there is no definite, canonical name for the two bytes of IPv6 addresses between colons. This forces people to use a description like I just did instead of a single, specific term.
I am ok with "quibble" but I don't think it will gain wide usage in the US. We use "quad" at work. G
On Thu, Nov 18, 2010 at 07:45:19PM -0800, George Bonser wrote:
Hi all,
as most of you are aware, there is no definite, canonical name for the two bytes of IPv6 addresses between colons. This forces people to use a description like I just did instead of a single, specific term.
I am ok with "quibble" but I don't think it will gain wide usage in the US. We use "quad" at work.
G
problem is, its not alwas ggoig to be two bytes... --bill
On Fri, Nov 19, 2010 at 07:00, <bmanning@vacation.karoshi.com> wrote:
problem is, its not alwas ggoig to be two bytes...
It's always two bytes, but people may choose to omit them. That is a social, not a (purely) technical, syntax, though.
Richard
That's exactly what I was going to say but didn't want to quibble. We tend to call them "quads" at work. What do you call that indeterminate space between two colons :: where it might be four or more zeros in there? That's a bunch of nibbles, maybe a "gulp"?
On 11/19/2010 4:57 AM, George Bonser wrote:
It's always two bytes, but people may choose to omit them. That is a social, not a (purely) technical, syntax, though.
Richard
That's exactly what I was going to say but didn't want to quibble. We tend to call them "quads" at work. What do you call that indeterminate space between two colons :: where it might be four or more zeros in there? That's a bunch of nibbles, maybe a "gulp"?
Yeah, I think I'd quibble with quibble; it's antagonistic. "Gulp" has serious potential in casual conversation (especially because you can refer to the excluded "::" portion as "the Big Gulp") but somehow I don't see it used in technical documentation. I like "morsel," personally. (Well, I also like "collop," because it's arcane and sounds vaguely dirty to me, but I don't think that would catch on.)
On Fri, Nov 19, 2010 at 10:57, George Bonser <gbonser@seven.com> wrote:
That's exactly what I was going to say but didn't want to quibble. We tend to call them "quads" at work. What do you call that indeterminate space between two colons :: where it might be four or more zeros in there? That's a bunch of nibbles, maybe a "gulp"?
I don't call it anything. "The fourth $decided_upon is zero/empty" suffices :) Though if that gap does not have a name yet, I suppose it can't hurt to try and think of a canonical name, either. Richard
On Nov 19, 2010, at 12:57 AM, Richard Hartmann wrote:
On Fri, Nov 19, 2010 at 07:00, <bmanning@vacation.karoshi.com> wrote:
problem is, its not alwas ggoig to be two bytes...
It's always two bytes, but people may choose to omit them. That is a social, not a (purely) technical, syntax, though.
It is always two bytes. A byte is not always an octet. Some machines do have byte sizes other than 8 bits, although few of them are likely to have IPv6 stacks, so, this may be an academic distinction at this point. Owen
On Fri, Nov 19, 2010 at 17:58, Owen DeLong <owen@delong.com> wrote:
It is always two bytes. A byte is not always an octet. Some machines do have byte sizes other than 8 bits
Vice versa. It's always two octects, but on some systems it may not be two bytes.
, although few of them are likely to have IPv6 stacks, so, this may be an academic distinction at this point.
Agreed. We can revisit this once we all own a few portable quantum computers, though :) Richard
On Nov 19, 2010, at 8:58 AM, Owen DeLong wrote:
On Nov 19, 2010, at 12:57 AM, Richard Hartmann wrote:
On Fri, Nov 19, 2010 at 07:00, <bmanning@vacation.karoshi.com> wrote:
problem is, its not alwas ggoig to be two bytes...
It's always two bytes, but people may choose to omit them. That is a social, not a (purely) technical, syntax, though.
Oops... Hit send too fast...
It is always two bytes. A byte is not always an octet. Some machines do
It is always two OCTETS. A byte is not always an octet...
have byte sizes other than 8 bits, although few of them are likely to have IPv6 stacks, so, this may be an academic distinction at this point.
Owen
On 11/19/10 10:56 AM, Owen DeLong wrote:
It is always two bytes. A byte is not always an octet. Some machines do
It is always two OCTETS. A byte is not always an octet...
Assuming you have a v6 stack on your cdc6600 a v6 address fits in 22 bytes not 16.
have byte sizes other than 8 bits, although few of them are likely to have IPv6 stacks, so, this may be an academic distinction at this point.
One can define that byte size for the purposes of the human reading of addresses ipv6 as 8 bits, without getting into machine specific details. what's important to the machine isn't the division of the address into parts (they aren't divided in the machine representation it's just one long row of bits) but rather where the mask falls.
Owen
If 8 bits is a byte, then 16 bits should be a mouthful. ;) Scott On 11/18/10 10:45 PM, George Bonser wrote:
Hi all,
as most of you are aware, there is no definite, canonical name for the two bytes of IPv6 addresses between colons. This forces people to use a description like I just did instead of a single, specific term.
I am ok with "quibble" but I don't think it will gain wide usage in the US. We use "quad" at work.
G
On Fri, 2010-11-19 at 17:06 +0100, Richard Hartmann wrote:
On Fri, Nov 19, 2010 at 14:14, Scott Morris <swm@emanon.com> wrote:
If 8 bits is a byte, then 16 bits should be a mouthful.
When does it become a meal and, more importantly, do you want to supper (sic) size?
The supersize option offered by e.g. McDonalds is not much larger than the normal meal size in my experience. So I guess, 8 bits = small, 16 bits = meal, 24 bits = supersize or something, but that doesn't fit well with IPv6 since each segment between colons is only 16 bits. We could call the :: part the 'liposection' though. William
I have a quibble with this discussion. When I defined a "byte" as "a mouthful of bits" to my boss back in 1977, he nearly fired me on the spot. He did not care about PDP-10 , much less PDP-11, data constructs. By now, octet has become essentially synonymous with byte and nibble with 4-bits. Could we just refer to "n octets"? Cutler For Reference Only: On Nov 19, 2010, at 11:06 AM, Richard Hartmann wrote:
On Fri, Nov 19, 2010 at 14:14, Scott Morris <swm@emanon.com> wrote:
If 8 bits is a byte, then 16 bits should be a mouthful.
When does it become a meal and, more importantly, do you want to supper (sic) size?
RIchard
James R. Cutler james.cutler@consultant.com
Given that a meal is often comprised of several mouthfuls, wouldn't it stand to reason that the entire address would suffice there? ;) Scott On 11/19/10 11:06 AM, Richard Hartmann wrote:
On Fri, Nov 19, 2010 at 14:14, Scott Morris <swm@emanon.com> wrote:
If 8 bits is a byte, then 16 bits should be a mouthful. When does it become a meal and, more importantly, do you want to supper (sic) size?
RIchard
On 19 November 2010 13:14, Scott Morris <swm@emanon.com> wrote:
If 8 bits is a byte, then 16 bits should be a mouthful.
I like that, but maybe a chomp (although that might annoy some perl & ruby people)... then maybe when all 2bytes are zeros and we expel them from the address with a double colon, we should call that a fart. -- Daniel Holme
On 20 Nov 2010, at 13:42, Daniel Holme <dan.holme@gmail.com> wrote:
On 19 November 2010 13:14, Scott Morris <swm@emanon.com> wrote:
If 8 bits is a byte, then 16 bits should be a mouthful.
I like that, but maybe a chomp (although that might annoy some perl & ruby people)... then maybe when all 2bytes are zeros and we expel them from the address with a double colon, we should call that a fart.
On a more serious note, apologies for throwing in more suggestions this late in the game. Especially now some documentation has been drafted, but has anybody thought of using 'munch' for 2bytes. It just seems to ring right for me. -- Daniel Holme
On Friday, November 19, 2010 08:14:52 am Scott Morris wrote:
If 8 bits is a byte, then 16 bits should be a mouthful.
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.
On Fri, Nov 19, 2010 at 08:14, Scott Morris <swm@emanon.com> wrote:
If 8 bits is a byte, then 16 bits should be a mouthful.
;)
Scott
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
On Nov 22, 2010, at 5:05 PM, TJ <trejrco@gmail.com> wrote:
On Fri, Nov 19, 2010 at 08:14, Scott Morris <swm@emanon.com> wrote:
If 8 bits is a byte, then 16 bits should be a mouthful.
Scott
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
I think each section should be a nom, and :: can be a om. My lolcat agrees.
Since the poll is a straight yes/no option with no preference, I will express my preference here. While I find the term quibble fun and amusing, I think hextet is a far more useful term because it does not have the overloaded human semantics that come with quibble. I'm sorry to quibble with the majority here, but, in this case, I think we have enough problems with ambiguous terminology in networking and this opportunity to avoid creating one more should not be missed. Owen On Nov 18, 2010, at 6:07 PM, Richard Hartmann wrote:
Hi all,
as most of you are aware, there is no definite, canonical name for the two bytes of IPv6 addresses between colons. This forces people to use a description like I just did instead of a single, specific term.
Being highly pedantic Germans, this annoyed quite a few people within the DENOG community. This, in turn, lead to an I-D[1]. If any of you have any additional suggestions, you are more than welcome to share them. Additionally, I want to invite everyone to participate in an informal poll which we created[2]. We're fully aware that it's trivial to cheat on this poll; that's life.
As of right now, Quibble leads with Hextet being a close second. All other options got significantly less votes.
Thanks, Richard
[1] http://tools.ietf.org/html/draft-denog-v6ops-addresspartnaming [2] http://doodle.com/5q9gfvk4qe6zmzc6
I saw 'field' somewhere.... http://tools.ietf.org/html/rfc5952#section-2.1 seems to agree. Frank On 11/19/2010 10:42 AM, Owen DeLong wrote:
Since the poll is a straight yes/no option with no preference, I will express my preference here. While I find the term quibble fun and amusing, I think hextet is a far more useful term because it does not have the overloaded human semantics that come with quibble.
I'm sorry to quibble with the majority here, but, in this case, I think we have enough problems with ambiguous terminology in networking and this opportunity to avoid creating one more should not be missed.
Owen
On Nov 18, 2010, at 6:07 PM, Richard Hartmann wrote:
Hi all,
as most of you are aware, there is no definite, canonical name for the two bytes of IPv6 addresses between colons. This forces people to use a description like I just did instead of a single, specific term.
Being highly pedantic Germans, this annoyed quite a few people within the DENOG community. This, in turn, lead to an I-D[1]. If any of you have any additional suggestions, you are more than welcome to share them. Additionally, I want to invite everyone to participate in an informal poll which we created[2]. We're fully aware that it's trivial to cheat on this poll; that's life.
As of right now, Quibble leads with Hextet being a close second. All other options got significantly less votes.
Thanks, Richard
[1] http://tools.ietf.org/html/draft-denog-v6ops-addresspartnaming [2] http://doodle.com/5q9gfvk4qe6zmzc6
On Fri, Nov 19, 2010 at 09:09, Frank Habicht <geier@geier.ne.tz> wrote:
I saw 'field' somewhere....
http://tools.ietf.org/html/rfc5952#section-2.1 seems to agree.
I seem to remember "field" being used with the understanding that it's a placeholder and not a definite term. As I can't find an actual source for that, I will have to get back to you once I found it. Richard
On Fri, Nov 19, 2010 at 08:42, Owen DeLong <owen@delong.com> wrote:
Since the poll is a straight yes/no option with no preference, I will express my preference here.
I considered using the Condorcet method [1] (modified for NotA), but as past experience has shown that people get easily confused by it, I decided to create a "plain" poll, instead.
While I find the term quibble fun and amusing, I think hextet is a far more useful term because it does not have the overloaded human semantics that come with quibble.
To be completely honest, while I did know the term, I had forgotten about it. This is part of the reason why I am seeking a wider audience. I'll add this consideration to the draft. I agree that this might be (not has to be) a deal breaker.
I'm sorry to quibble with the majority here, but, in this case, I think we have enough problems with ambiguous terminology in networking and this opportunity to avoid creating one more should not be missed.
Agreed. OTOH, Hextet is not technically correct while appearing to be so. Thanks a lot, Richard [1] http://en.wikipedia.org/wiki/Condorcet_method
I'm sorry to quibble with the majority here, but, in this case, I think we have enough problems with ambiguous terminology in networking and this opportunity to avoid creating one more should not be missed.
(The above paragraph was mainly so that I had an opportunity to toss quibble into the text with it's other meaning).
Agreed. OTOH, Hextet is not technically correct while appearing to be so.
True... The correct term would be decohextet, but, decohextet is rather long both to say and to write and really doesn't roll off the tongue the way hextet does. Owen
Greetings, On Fri, 19 Nov 2010, Owen DeLong wrote:
I'm sorry to quibble with the majority here, but, in this case, I think we have enough problems with ambiguous terminology in networking and this opportunity to avoid creating one more should not be missed.
(The above paragraph was mainly so that I had an opportunity to toss quibble into the text with it's other meaning).
Agreed. OTOH, Hextet is not technically correct while appearing to be so.
True... The correct term would be decohextet, but, decohextet is rather long both to say and to write and really doesn't roll off the tongue the way hextet does.
I like to call it a "HexNot" - a hexidecimal representation of zeros. :: --- Jay Nugent () ascii ribbon campaign in /\ support of plain text e-mail Train how you will Operate, and you will Operate how you were Trained. +------------------------------------------------------------------------+ | Jay Nugent jjn@nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller | | ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring | | Web-Pegasus [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts| +------------------------------------------------------------------------+ 12:01pm up 72 days, 21:25, 3 users, load average: 0.15, 0.07, 0.05
On Thu, Nov 18, 2010 at 9:07 PM, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
as most of you are aware, there is no definite, canonical name for the two bytes of IPv6 addresses between colons. This forces people to use a description like I just did instead of a single, specific term.
Hi Richard, I have an anti-naming proposal: Allow users to place the colons -anywhere- or even leave them out altogether without changing the semantics of the IPv6 address. The colons are there for readability purposes only. They have no special significance and should not be elevated to significance by naming the parts of the address they delineate. Treat them specially and some fools will attach importance to arranging tasks on two-byte boundaries. The meaningful boundaries in the protocol itself are nibble and /64. If you want socially significant boundaries, add /12, /32 and /48. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 11/19/10 12:45 PM, William Herrin wrote:
On Thu, Nov 18, 2010 at 9:07 PM, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
as most of you are aware, there is no definite, canonical name for the two bytes of IPv6 addresses between colons. This forces people to use a description like I just did instead of a single, specific term.
Hi Richard,
I have an anti-naming proposal: Allow users to place the colons -anywhere- or even leave them out altogether without changing the semantics of the IPv6 address.
The colons are there for readability purposes only. They have no special significance and should not be elevated to significance by naming the parts of the address they delineate. Treat them specially and some fools will attach importance to arranging tasks on two-byte boundaries.
The meaningful boundaries in the protocol itself are nibble and /64. If you want socially significant boundaries, add /12, /32 and /48.
It is possible and desirable to be able to describe any mask length between /0 and /128. the /64 is an important demarcation point for subnets but everything shorter than that will appear in your routing table.
Regards, Bill Herrin
On Fri, Nov 19, 2010 at 4:09 PM, Joel Jaeggli <joelja@bogus.com> wrote:
On 11/19/10 12:45 PM, William Herrin wrote:
The meaningful boundaries in the protocol itself are nibble and /64. If you want socially significant boundaries, add /12, /32 and /48.
It is possible and desirable to be able to describe any mask length between /0 and /128. the /64 is an important demarcation point for subnets but everything shorter than that will appear in your routing table.
Hi Joel, Bit, nibble and /64 then. /64 is treated specially by functions in the protocol (like SLAAC) thus it's a protocol boundary rather than a social one (/12 IANA allocations, /32 ISP allocations, /48 end-user assignments). Unless you particularly feel the need to assign /64's to router loopbacks, you'll see plenty of routes longer than /64 in your table too. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Fri, Nov 19, 2010 at 22:17, William Herrin <bill@herrin.us> wrote:
Bit, nibble and /64 then. /64 is treated specially by functions in the protocol (like SLAAC) thus it's a protocol boundary rather than a social one (/12 IANA allocations, /32 ISP allocations, /48 end-user assignments).
I would argue that /0 and /128 are somewhat special, too.
Unless you particularly feel the need to assign /64's to router loopbacks, you'll see plenty of routes longer than /64 in your table too.
That's a personal preference, really. Unless you mess up, or are an end user permanently stuck with a /64 (in which case your ISP messed up), there isn't really much need to assign anything longer, though. That being said, for whatever reason, several of my upstreams use /126 for their sessions. In any case, other than "some people might see the colons as magic markers" I don't really see an argument in favour of avoiding a common name. And that does not seem to hold much water. This is not meant to be an attack, I simply wonder if I am missing something. Richard
On Fri, Nov 19, 2010 at 21:45, William Herrin <bill@herrin.us> wrote:
I have an anti-naming proposal: Allow users to place the colons -anywhere- or even leave them out altogether without changing the semantics of the IPv6 address.
A decade or two of established syntax disagree. IPv6 addresses, UUIDs and similar have a unique syntax for a reason. Otherwise, we, nor computers, wouldn't be able to quickly distinguish an IP from a hash.
The colons are there for readability purposes only. They have no special significance and should not be elevated to significance by naming the parts of the address they delineate. Treat them specially and some fools will attach importance to arranging tasks on two-byte boundaries.
Even if they were for readability only, they would still be for humans. Same as the specific, canonical name we are trying to agree on. If people want to interpret more into the colons than there is to see, they will do so regardless of a name. The rest of us will work faster, more efficiently and not explain the same old thing a gazillion times. Richard
On Fri, Nov 19, 2010 at 4:20 PM, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
On Fri, Nov 19, 2010 at 21:45, William Herrin <bill@herrin.us> wrote:
I have an anti-naming proposal: Allow users to place the colons -anywhere- or even leave them out altogether without changing the semantics of the IPv6 address.
A decade or two of established syntax disagree. IPv6 addresses, UUIDs and similar have a unique syntax for a reason. Otherwise, we, nor computers, wouldn't be able to quickly distinguish an IP from a hash.
Hi Richard, I thought about that. Have a "one colon rule" that IPv6 addresses in hexidecimal format have to include at least one colon somewhere. The regex which picks that token out versus the other possibilities is easy enough to write and so is the human rule: "Oh, it's got hexidecimal digits and a colon in it. IPv6 address." There is one serious problem with switching notations: we've already started dropping the leading 0's inside each coloned-off section, and that would have a different meaning if the colons could be placed anywhere. fd00:68::1 and fd:0068::1 mean different things now. The former means fd00:0068::1 while the latter means 00fd:0068::1. I would instead have them mean the same thing: fd00:6800::1. The single-colon separator gets syntax but no semantics and the :: separator means "all middle nibbles are zero" instead of "all middle two-byte components are zero." I mean, when you think about it, the consequence that :: means "all middle two-byte components are zero" is kinda weird.
Even if they were for readability only, they would still be for humans. Same as the specific, canonical name we are trying to agree on.
If people want to interpret more into the colons than there is to see, they will do so regardless of a name.
Anything you call out will be interpreted as special. The more you call it out, the greater the expectation that the distinction is important. That's human nature. You've explained netmasks before to folks whose brains couldn't get past the dots in the address. We all have. And referring to IP address notation as "dotted quads" just reinforces classful addressing concepts so that folks assigning themselves 10/8 subnets damn near always split on /16 and /24 boundaries.
The rest of us will work faster, more efficiently and not explain the same old thing a gazillion times.
And even more efficiently when we don't have to repeatedly explain that the mental model implied by the notation style is, in fact, not how the technology actually works. On Fri, Nov 19, 2010 at 4:31 PM, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
In any case, other than "some people might see the colons as magic markers" I don't really see an argument in favour of avoiding a common name. And that does not seem to hold much water. This is not meant to be an attack, I simply wonder if I am missing something.
No sweat. When I shoot my mouth off, I expect to be challenged on the remarks. Part of the fun lies in discovering whether the thesis is defensible. By the by, as long as I'm criticizing IPv6 notation, let me express just how poor a choice of separator character the colon is. The colon separates the IPv4 address from a directory or port description only slightly less often than the slash. Writing the parsers to handle an IPv6 address as a drop in is a pain in the tail. Should have used a dash, underscore or plus. Those are far more rarely used in tokenization. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Fri, Nov 19, 2010 at 23:52, William Herrin <bill@herrin.us> wrote:
I thought about that. Have a "one colon rule" that IPv6 addresses in hexidecimal format have to include at least one colon somewhere. The regex which picks that token out versus the other possibilities is easy enough to write and so is the human rule: "Oh, it's got hexidecimal digits and a colon in it. IPv6 address."
Even if this were feasible at this point, and it's not, this would still make it hard for humans to detect an IPv6 address at a glance, makes it impossible to quickly pick out any sections that are more relevant at the moment and would hog the colon for all eternity, blocking it for other uses. Also, this would make adding a port even more cumbersome.
fd00:68::1 and fd:0068::1 mean different things now. The former means fd00:0068::1 while the latter means 00fd:0068::1. I would instead have them mean the same thing: fd00:6800::1. The single-colon separator gets syntax but no semantics
I am not sure if this would actually be an advantage.
and the :: separator means "all middle nibbles are zero" instead of "all middle two-byte components are zero."
Putting the burden of parsing that on humans (and computers). Same as modern compression algorithms are optimized to doing more work while encoding and less work during decoding, it does not really make sense to make it harder to understand an address while reading it for the dubious gain of saving up to six colons.
I mean, when you think about it, the consequence that :: means "all middle two-byte components are zero" is kinda weird.
It's a commonly accepted, well-defined convention to save humans effort while not sacrificing readability. There are weirder things in technology.
Anything you call out will be interpreted as special. The more you call it out, the greater the expectation that the distinction is important. That's human nature.
Pattern recognition is a central part of our intelligence, so yes, it's human nature. This is not necessarily a bad thing. While I agree that some of the delimitations are social, rather than technical, it's still useful to have them. If this results in some people not assigning their customers a /56 cause it looks funny, so be it.
You've explained netmasks before to folks whose brains couldn't get past the dots in the address. We all have.
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".
And referring to IP address notation as "dotted quads" just reinforces classful addressing concepts so that folks assigning themselves 10/8 subnets damn near always split on /16 and /24 boundaries.
And why shouldn't they? Unless they are a large ISP or similar, they will have enough space for pretty much everything they ever need to do. It's as good as anything and it allows people to be somewhat familiar with this stuff. Not everyone is an expert and that is fine. Personally, I have no motivation whatsoever to _truly_ understand _everything_ that's involved in today's wireless systems. Still, it's nice that I can use them reliably without needing this level of involvement.
And even more efficiently when we don't have to repeatedly explain that the mental model implied by the notation style is, in fact, not how the technology actually works.
If the person can grasp what a bit vector is, they will understand. If they don't, they will not understand it anyway and I won't waste time trying to explain it in depth. At least as of right now, you are giving those people some middle ground which allows them to have a good working knowledge to use IPv6 reliably without needing this level of involvement.
No sweat. When I shoot my mouth off, I expect to be challenged on the remarks. Part of the fun lies in discovering whether the thesis is defensible.
For at least a few rounds, I am usually good for that, too. Personally, I think I answered the implicit question above, but it made me re-asses and re-think my personal & professional opinion on quite a few things and that's a Good Thing, from time to time.
By the by, as long as I'm criticizing IPv6 notation, let me express just how poor a choice of separator character the colon is. The colon separates the IPv4 address from a directory or port description only slightly less often than the slash. Writing the parsers to handle an IPv6 address as a drop in is a pain in the tail. Should have used a dash, underscore or plus. Those are far more rarely used in tokenization.
A dash is the character people use when there is not a standard. Look at what they had to do for UUIDs to make them recognizable (which worked out really well, especially the version encoding. I really like their solution). Though they had the advantage that substring length _really_ doesn't matter other than as a way to correctly distinguish UUIDs from anything else. I don't really like the colon either, but I can't think of an alternative, either. Richard PS: Yes, I am fully aware that my complete email is moot anyway as the IPv6 syntax will not change, ever. I wrote it for fun :)
On Sat, Nov 20, 2010 at 5:05 AM, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
On Fri, Nov 19, 2010 at 23:52, William Herrin <bill@herrin.us> wrote:
I thought about that. Have a "one colon rule" that IPv6 addresses in hexidecimal format have to include at least one colon somewhere. The regex which picks that token out versus the other possibilities is easy enough to write and so is the human rule: "Oh, it's got hexidecimal digits and a colon in it. IPv6 address."
this would still make it hard for humans to detect an IPv6 address at a glance, makes it impossible to quickly pick out any sections that are more relevant at the moment
Which is why you wouldn't conventionally remove the colons even though the format would allow it. You might, however, move the colons to highlight the delineations relevant to a particular address rather than the meaningless two-byte separation. For example: 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 fd:1234567890:abcd::1 fd - ULA space 1234567890 - ULA global ID abcd - user subnet ::1 - LAN address Instead of this meaning-filled separation, we have: 260a:bcde:1234:5698::1 which doesn't tell us a single helpful thing about how that address is organized. The only thing the colons do there is make it easier to blindly transcribe, like the dashes in a CD license key.
and would hog the colon for all eternity, blocking it for other uses. Also, this would make adding a port even more cumbersome.
I've written more than a few parsers. I think your concern here is overstated.
Anything you call out will be interpreted as special. The more you call it out, the greater the expectation that the distinction is important. That's human nature.
Pattern recognition is a central part of our intelligence, so yes, it's human nature. This is not necessarily a bad thing.
The way you talk about something trains people how that thing works. Train them poorly and it's your fault when their mistaken mental model results in errors.
I mean, when you think about it, the consequence that :: means "all middle two-byte components are zero" is kinda weird.
It's a commonly accepted, well-defined convention to save humans effort while not sacrificing readability. There are weirder things in technology.
I have no beef with the the notion of abbreviations. I'm just saying this particular formulation is weird, a consequence of a poorly thought-out notation format.
And even more efficiently when we don't have to repeatedly explain that the mental model implied by the notation style is, in fact, not how the technology actually works.
If the person can grasp what a bit vector is, they will understand. If they don't, they will not understand it anyway and I won't waste time trying to explain it in depth. At least as of right now, you are giving those people some middle ground which allows them to have a good working knowledge to use IPv6 reliably without needing this level of involvement.
It helps if the notation style reminds them that they're dealing with a bit vector. IPv6 is better about this than IPv4; at least the colons aren't separating portions of the bit pattern expressed in base-10. But it could be better. Fixed separations get folks thinking there's a higher significance. Movable separations offers a constant reminder that it is just a bit vector.
No sweat. When I shoot my mouth off, I expect to be challenged on the remarks. Part of the fun lies in discovering whether the thesis is defensible.
For at least a few rounds, I am usually good for that, too. Personally, I think I answered the implicit question above, but it made me re-asses and re-think my personal & professional opinion on quite a few things and that's a Good Thing, from time to time.
A value I also find when I'm on the receiving end. :)
PS: Yes, I am fully aware that my complete email is moot anyway as the IPv6 syntax will not change, ever. I wrote it for fun :)
Yep. However, there is one thing that could be done at this juncture: intentionally don't name the two-byte groupings. And then make that a part of the lesson plan: by the way folks, these groupings of four characters in the IPv6 address intentionally have no name. That's because the IPv6 address is a bit vector. The colons are only there to make it easier to read and type; the groupings have no significance. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Nov 20, 2010, at 9:12 AM, William Herrin wrote:
On Sat, Nov 20, 2010 at 5:05 AM, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
On Fri, Nov 19, 2010 at 23:52, William Herrin <bill@herrin.us> wrote:
I thought about that. Have a "one colon rule" that IPv6 addresses in hexidecimal format have to include at least one colon somewhere. The regex which picks that token out versus the other possibilities is easy enough to write and so is the human rule: "Oh, it's got hexidecimal digits and a colon in it. IPv6 address."
this would still make it hard for humans to detect an IPv6 address at a glance, makes it impossible to quickly pick out any sections that are more relevant at the moment
Which is why you wouldn't conventionally remove the colons even though the format would allow it. You might, however, move the colons to highlight the delineations relevant to a particular address rather than the meaningless two-byte separation.
How do you propose to get the router to regurgitate this?
For example:
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
fd:1234567890:abcd::1
fd - ULA space 1234567890 - ULA global ID abcd - user subnet ::1 - LAN address
From the data available in BGP today, this is a relatively arbitrary positioning of the delimiters. I would propose that for a proposed syntax to be worthy of consideration it must be possible to reproduce it reliably in an automated fashion. Owen
Instead of this meaning-filled separation, we have:
260a:bcde:1234:5698::1
which doesn't tell us a single helpful thing about how that address is organized. The only thing the colons do there is make it easier to blindly transcribe, like the dashes in a CD license key.
and would hog the colon for all eternity, blocking it for other uses. Also, this would make adding a port even more cumbersome.
I've written more than a few parsers. I think your concern here is overstated.
Anything you call out will be interpreted as special. The more you call it out, the greater the expectation that the distinction is important. That's human nature.
Pattern recognition is a central part of our intelligence, so yes, it's human nature. This is not necessarily a bad thing.
The way you talk about something trains people how that thing works. Train them poorly and it's your fault when their mistaken mental model results in errors.
I mean, when you think about it, the consequence that :: means "all middle two-byte components are zero" is kinda weird.
It's a commonly accepted, well-defined convention to save humans effort while not sacrificing readability. There are weirder things in technology.
I have no beef with the the notion of abbreviations. I'm just saying this particular formulation is weird, a consequence of a poorly thought-out notation format.
And even more efficiently when we don't have to repeatedly explain that the mental model implied by the notation style is, in fact, not how the technology actually works.
If the person can grasp what a bit vector is, they will understand. If they don't, they will not understand it anyway and I won't waste time trying to explain it in depth. At least as of right now, you are giving those people some middle ground which allows them to have a good working knowledge to use IPv6 reliably without needing this level of involvement.
It helps if the notation style reminds them that they're dealing with a bit vector. IPv6 is better about this than IPv4; at least the colons aren't separating portions of the bit pattern expressed in base-10. But it could be better. Fixed separations get folks thinking there's a higher significance. Movable separations offers a constant reminder that it is just a bit vector.
No sweat. When I shoot my mouth off, I expect to be challenged on the remarks. Part of the fun lies in discovering whether the thesis is defensible.
For at least a few rounds, I am usually good for that, too. Personally, I think I answered the implicit question above, but it made me re-asses and re-think my personal & professional opinion on quite a few things and that's a Good Thing, from time to time.
A value I also find when I'm on the receiving end. :)
PS: Yes, I am fully aware that my complete email is moot anyway as the IPv6 syntax will not change, ever. I wrote it for fun :)
Yep. However, there is one thing that could be done at this juncture: intentionally don't name the two-byte groupings. And then make that a part of the lesson plan: by the way folks, these groupings of four characters in the IPv6 address intentionally have no name. That's because the IPv6 address is a bit vector. The colons are only there to make it easier to read and type; the groupings have no significance.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 11/20/10 2:20 PM, Owen DeLong wrote:
On Nov 20, 2010, at 9:12 AM, William Herrin wrote:
On Sat, Nov 20, 2010 at 5:05 AM, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
On Fri, Nov 19, 2010 at 23:52, William Herrin <bill@herrin.us> wrote:
I thought about that. Have a "one colon rule" that IPv6 addresses in hexidecimal format have to include at least one colon somewhere. The regex which picks that token out versus the other possibilities is easy enough to write and so is the human rule: "Oh, it's got hexidecimal digits and a colon in it. IPv6 address."
this would still make it hard for humans to detect an IPv6 address at a glance, makes it impossible to quickly pick out any sections that are more relevant at the moment
Which is why you wouldn't conventionally remove the colons even though the format would allow it. You might, however, move the colons to highlight the delineations relevant to a particular address rather than the meaningless two-byte separation.
How do you propose to get the router to regurgitate this?
Since I've been reading old drafts recently I think we can thank mike o'dell for the term "routing goop". the problem of course is you can't distinguish which part of the routing goop is signficant (to the humans) unless you have an apriori mapping. otherwise all you have is some goop and a mask which together are a route.
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?
fd00:68::1 and fd:0068::1 mean different things now. The former means fd00:0068::1 while the latter means 00fd:0068::1. I would instead have them mean the same thing: fd00:6800::1. The single-colon separator gets syntax but no semantics
I am not sure if this would actually be an advantage.
It would actually be a huge disadvantage. Following the principle of least surprise, whether you like it or not, the multiple colons rule is useful for making IPv6 address human factors better. Additionally, humans will tend to default to seeing the areas between colons as number fields. As such, they expect them to be right justified with leading zeros optional. Dropping trailing zeroes will inevitably lead to more misinterpretations and errors than keeping them. Where this becomes unfortunate is when people make the mistake of writing things like fd/8 or worse, fd::/8. Technically both of these are not correct. fd/8 is simply invalid syntax. The human eye will turn it into fd00::/8 because that's the only possible logical meaning that makes any sense. fd::/8 is worse because the human eye will turn it into fd00::/8 as that is again, the only sensible thing it could represent, while, in fact, as written it means 0::/8. For intuitive reading, things should always be written right justified. No one will misinterpret fd00::/8 or 2001:0d00::/24. Many will misinterpret fd::/8 and 2001:0d::/24.
and the :: separator means "all middle nibbles are zero" instead of "all middle two-byte components are zero."
Putting the burden of parsing that on humans (and computers). Same as modern compression algorithms are optimized to doing more work while encoding and less work during decoding, it does not really make sense to make it harder to understand an address while reading it for the dubious gain of saving up to six colons.
In reality the most you would gain from such a practice would be to save two colons. The other 4 could already be eliminated by the :: in current practice.
I mean, when you think about it, the consequence that :: means "all middle two-byte components are zero" is kinda weird.
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.
Anything you call out will be interpreted as special. The more you call it out, the greater the expectation that the distinction is important. That's human nature.
Pattern recognition is a central part of our intelligence, so yes, it's human nature. This is not necessarily a bad thing.
While I agree that some of the delimitations are social, rather than technical, it's still useful to have them. If this results in some people not assigning their customers a /56 cause it looks funny, so be it.
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.
You've explained netmasks before to folks whose brains couldn't get past the dots in the address. We all have.
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.
And referring to IP address notation as "dotted quads" just reinforces classful addressing concepts so that folks assigning themselves 10/8 subnets damn near always split on /16 and /24 boundaries.
And why shouldn't they? Unless they are a large ISP or similar, they will have enough space for pretty much everything they ever need to do. It's as good as anything and it allows people to be somewhat familiar with this stuff.
Not everyone is an expert and that is fine. Personally, I have no motivation whatsoever to _truly_ understand _everything_ that's involved in today's wireless systems. Still, it's nice that I can use them reliably without needing this level of involvement.
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.
And even more efficiently when we don't have to repeatedly explain that the mental model implied by the notation style is, in fact, not how the technology actually works.
If the person can grasp what a bit vector is, they will understand. If they don't, they will not understand it anyway and I won't waste time trying to explain it in depth. At least as of right now, you are giving those people some middle ground which allows them to have a good working knowledge to use IPv6 reliably without needing this level of involvement.
Agreed.
No sweat. When I shoot my mouth off, I expect to be challenged on the remarks. Part of the fun lies in discovering whether the thesis is defensible.
For at least a few rounds, I am usually good for that, too. Personally, I think I answered the implicit question above, but it made me re-asses and re-think my personal & professional opinion on quite a few things and that's a Good Thing, from time to time.
Should we all sing kumbayah now?
By the by, as long as I'm criticizing IPv6 notation, let me express just how poor a choice of separator character the colon is. The colon separates the IPv4 address from a directory or port description only slightly less often than the slash. Writing the parsers to handle an IPv6 address as a drop in is a pain in the tail. Should have used a dash, underscore or plus. Those are far more rarely used in tokenization.
A dash is the character people use when there is not a standard. Look at what they had to do for UUIDs to make them recognizable (which worked out really well, especially the version encoding. I really like their solution). Though they had the advantage that substring length _really_ doesn't matter other than as a way to correctly distinguish UUIDs from anything else.
Underscore is a particularly poor choice for a variety of reasons, not the least of which is the resulting legibility of things like: 2001_db8_f3ed__202_3/48 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. + would be interesting, but, I believe it also has overloaded semantics and would make addresses look like a math problem in hex anyway: 2001+db8+5f03++32/48 Is that 2001:db8:5f03::32/48 or is that 8cbd.43 (hex fraction approximated) I'd say that loses on both human readability and parser ambiguity too,. Other entertaining possible delimiters worthy of consideration might be: Letter v 2001vdb8v5f03vv32/48 Pretty hard to read. :( Letter I 2001Idb8I5f03II32/48 Also hard to read. :( Hash # 2001#db8#5f03##32/48 This makes a hash of it, but, not too hard to read and not ambiguous. Splat * 2001*db8*5f03**32/48 Not bad, but, who wants to type this into unix systems? B-tick ` 2001`db8`5f03``32/48 Even MORE fun on a unix system. F-tick ' 2001'db8'5f03''32/48 Yet more UNIX fun. Quote " 2001"db8"5f03""32/48 See above 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 (:) is the worst choice except for all the others. Owen
On Sat, Nov 20, 2010 at 5:15 PM, Owen DeLong <owen@delong.com> wrote:
fd00:68::1 and fd:0068::1 mean different things now. The former means fd00:0068::1 while the latter means 00fd:0068::1. I would instead have them mean the same thing: fd00:6800::1. The single-colon separator gets syntax but no semantics
I am not sure if this would actually be an advantage.
It would actually be a huge disadvantage. [...]
Where this becomes unfortunate is when people make the mistake of writing things like fd/8 or worse, fd::/8. Technically both of these are not correct. fd/8 is simply invalid syntax. The human eye will turn it into fd00::/8 because that's the only possible logical meaning that makes any sense.
fd::/8 is worse because the human eye will turn it into fd00::/8 as that is again, the only sensible thing it could represent, while, in fact, as written it means 0::/8.
So... You just dissed my screed about IPv6 notation and then offered two fantastic arguments why I'm right... 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. 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? 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.
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.
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.
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. This has always been a PIA for me any time I need to copy a MAC address in to or out of a Cisco config.
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 (:) is the worst choice except for all the others.
Could have stuck with dot and forgone "::192.168.1.1". Or replaced the v4 dot with a dash in that scenario. Could have gone with comma and quoted the address in CSV files like you do for any text value that isn't trivial, instead of bracketing it in much more commonly used URLs.
For example:
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
How do you propose to get the router to regurgitate this?
I don't. The colons float. If the address was learned dynamically, the router can regurgitate it any way it wants. 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. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 11/21/10 7:54 AM, William Herrin wrote:
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.
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.
The benefits of hindsight are myriad... The uri schema is contemporaneous with rfc 1883 as is a lot of formative work in a lot of areas 1992-1994 range. 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.
On Sun, Nov 21, 2010 at 11:40 AM, Joel Jaeggli <joelja@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. 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. 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@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@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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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
The problem with movable separators is in handling zeros. If the separators are a known distance apart, zeros can be deduced. The example above has only one zero. Imagine it were a different address: 260a:0:8:65::1 Now with movable separators the the zeros would be explicit because you don't know how far apart the colons are n the address. In your example, it would become: 260:a00:0000:0800:65::1 because there is no way to tell from a movable colon address how many places the colon was moved and how many zeros there are between them. You can move colons as long as zeros are explicit but you must have fixed colons if zeros are implicit. Otherwise there is no way to deduce where the zeros go from simply parsing the address.
On 11/21/10 2:50 PM, William Herrin wrote:
On Sun, Nov 21, 2010 at 11:40 AM, Joel Jaeggli <joelja@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@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@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
On Sun, Nov 21, 2010 at 5:15 PM, Owen DeLong <owen@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.
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
-Bill
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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. On Sun, Nov 21, 2010 at 23:50, William Herrin <bill@herrin.us> wrote:
On Sun, Nov 21, 2010 at 11:40 AM, Joel Jaeggli <joelja@bogus.com> wrote:
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.
On Sun, Nov 21, 2010 at 1:42 PM, <Valdis.Kletnieks@vt.edu> wrote:
Whatever you want to do. That's the point of optional/movable separators.
Principle of least surprise.
On Sun, Nov 21, 2010 at 5:15 PM, Owen DeLong <owen@delong.com> wrote:
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.
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
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.
Windows displays macs as dash separated hexified bytes (ie, 12-34-56-78-90-AB) which is incorrect. Given how widespread and pervasive the Microsoft Windows Virus is, I'd call this widespread and pervasive.
On Nov 26, 2010, at 2:11 PM, kmedcalf@dessus.com wrote:
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.
Windows displays macs as dash separated hexified bytes (ie, 12-34-56-78-90-AB) which is incorrect.
Given how widespread and pervasive the Microsoft Windows Virus is, I'd call this widespread and pervasive.
Windows is not a virus. Viruses are tight, well written pieces of code with a specific (usually nefarious) purpose. While windows certainly qualifies as nefarious, I doubt anyone would consider it tight or well written code. Owen
Since 11/18/10 this discussion has generated something like 66 messages across five threads on this list, on nanog and elsewhere. While some suggestions are entertaining, I would think of this criticism and commentary on the document as useful if it winnowed the number of options down to fewer rather than more. e.g. the positive result and the path to advancement of this draft would be when the document produces a solid recommendation on address part naming rather than several of them. Several recomendations do not get us further down the road to a common set of terminology. thanks joel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/29/2010 11:59, Joel Jaeggli wrote: | Since 11/18/10 this discussion has generated something like 66 messages | across five threads on this list, on nanog and elsewhere. | | While some suggestions are entertaining, I would think of this criticism | and commentary on the document as useful if it winnowed the number of | options down to fewer rather than more. e.g. the positive result and the | path to advancement of this draft would be when the document produces a | solid recommendation on address part naming rather than several of them. | | Several recomendations do not get us further down the road to a common | set of terminology. If you're looking for serious feedback: 1. Any term using > 1 word is out 2. Any word using > 2 syllables is out 3. I've never had a problem calling it "field," I think that 5952 is a perfectly good normative ref for that, and I don't understand what the fuss is about. :) hth, Doug - -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM9A5mAAoJEFzGhvEaGryEGxEH/3rs0yOYma3fWHnHc20+fxPu CTcziNHpjjkvI0bAv0V+NFAxXO350iyv18KqufyEvCuGbkT/AETfOLAr+QsDa09X vvE7/sO+XEBNuGI1f2IZiDDZQ9M4u1L5Hx+stJ6chxASXzBUHPJdNamO5DbmKU6H Wxic2+XEtBl/EvX4yB/yBJOwT7R+gjgWcQjCZ06aPmi0N45fGohhsutv7fE93qlm GCxp6zQisr88rgdgs6HyJgwc36ZmVFCqEoT8IYBYDxwWYc28S4Wb0WWd3R3rs13E 3eNysvRPPv0UxALYgecLKc/C0HOTQjfgS4YplbFL/ltHzIRLs6qPXUJyNT3XC+4= =YBMa -----END PGP SIGNATURE-----
On Mon, Nov 29, 2010 at 21:34, Doug Barton <dougb@dougbarton.us> wrote:
If you're looking for serious feedback:
We are.
3. I've never had a problem calling it "field," I think that 5952 is a perfectly good normative ref for that, and I don't understand what the fuss is about. :)
I seem to remember one of the authors of the initial RFCs telling us that they went with field with the understanding that it's so generic that someone could/would think of something else down the road. I didn't have time to really search for that mail, though. The fact that GMail is refusing to display quite a few mails atm (or serve them via SMTP) does not help, either. Most of my draft-related emails are amongst that... To give a short summary of the current status: Hextet received the most votes by far, followed by quibble. Everything else didn't get nearly as much support. Quad has been suggested a lot of times, but its meaning within the C/C++ world and very frequent use within the Kame stack sadly makes this a no-go. Quibble already has a meaning in English and a negative one, at that. Hextet is incorrect if you are being pedantic, but it's reasonably unique so that you don't have to call it "IPv6 hextet" to avoid confusion. Given all of the above, my personal opinion is that hextet will come out as the winner. Richard PS: Thanks to Joel. I was contemplating how to refocus the whole thing and he did our job for us; and nicely.
On Nov 21, 2010, at 7:54 AM, William Herrin wrote:
On Sat, Nov 20, 2010 at 5:15 PM, Owen DeLong <owen@delong.com> wrote:
fd00:68::1 and fd:0068::1 mean different things now. The former means fd00:0068::1 while the latter means 00fd:0068::1. I would instead have them mean the same thing: fd00:6800::1. The single-colon separator gets syntax but no semantics
I am not sure if this would actually be an advantage.
It would actually be a huge disadvantage. [...]
Where this becomes unfortunate is when people make the mistake of writing things like fd/8 or worse, fd::/8. Technically both of these are not correct. fd/8 is simply invalid syntax. The human eye will turn it into fd00::/8 because that's the only possible logical meaning that makes any sense.
fd::/8 is worse because the human eye will turn it into fd00::/8 as that is again, the only sensible thing it could represent, while, in fact, as written it means 0::/8.
So... You just dissed my screed about IPv6 notation and then offered two fantastic arguments why I'm right... 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.
That's not a reason you're correct, it's a recognition of one of the warts in the current system and a statement that on the rare occasion when people are writing IPv6 addresses, they need to do so with care. So long as one writes the IPv6 address correctly, it is not hard to read. There is no problem with the understanding of fd00::/8 for both humans and machines. In fact, fd::/8 would be interpreted, I estimate, by approximately 80% of people as fd00::/8 and by the other 20% who are used to working with numbers and computers as 00fd::/8 until they realized that the person responsible for that scrawl must have meant fd00::/8. Thus, it is an ambiguous representation open to convenient misinterpretation. The problem with your idea comes when we move on to fd::/16. In the current system, this is a valid syntax for 00fd::/16. In your system, would this mean 00fd::/16 or would it mean fd00::/16? Both are equally valid as I see it. Certainly there is the likelihood for much confusion even if you have rules that cover it.
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.
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.
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.
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.
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).
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.
Really, there's no advantage whatsoever to this. All it does is make talking about address structure more complicated. Having a universal name will reduce the occurrence of local arbitrary naming which I believe is a useful practice.
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. This has always been a PIA for me any time I need to copy a MAC address in to or out of a Cisco config.
Doesn't matter... It's widespread and Cisco isn't the only one to use it. As such, doing this to IPv6 addresses is a recipe for pain.
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 (:) is the worst choice except for all the others.
Could have stuck with dot and forgone "::192.168.1.1". Or replaced the v4 dot with a dash in that scenario. Could have gone with comma and quoted the address in CSV files like you do for any text value that isn't trivial, instead of bracketing it in much more commonly used URLs.
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.
For example:
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
How do you propose to get the router to regurgitate this?
I don't. The colons float. If the address was learned dynamically, the router can regurgitate it any way it wants.
Yeah, because it's always good for human factors when the output showing an address bears little or no resemblance to the way the user expects it to be written. NOT!
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.
Which, IMO, is a good reason the current system is superior. Fewer surprises==better human factors engineering. Owen
On Sun, Nov 21, 2010 at 23:15, Owen DeLong <owen@delong.com> wrote:
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
On Sun, Nov 21, 2010 at 16:54, William Herrin <bill@herrin.us> wrote:
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
On Mon, Nov 22, 2010 at 6:40 AM, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
On Sun, Nov 21, 2010 at 16:54, William Herrin <bill@herrin.us> wrote:
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.
On Sun, Nov 21, 2010 at 23:50, William Herrin <bill@herrin.us> wrote:
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Mon, Nov 22, 2010 at 15:07, William Herrin <bill@herrin.us> wrote:
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
On Sat, Nov 20, 2010 at 23:15, Owen DeLong <owen@delong.com> wrote: 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 (:) is the worst choice except for all the others.
Agreed. Richard
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. :p 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
On Mon, Nov 22, 2010 at 16:23, Owen DeLong <owen@delong.com> wrote:
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
participants (21)
-
bmanning＠vacation.karoshi.com -
Cutler James R -
Daniel Holme -
David Israel -
Doug Barton -
Frank Habicht -
George Bonser -
Janet Sullivan -
Jay Nugent -
Joel Jaeggli -
kmedcalf＠dessus.com -
Lamar Owen -
Michael Dillon -
Nick Hilliard -
Owen DeLong -
Richard Hartmann -
Scott Morris -
TJ -
Valdis.Kletnieks＠vt.edu -
William Herrin -
William Pitcock