Subject: Changing DHCP related text in privacy-addrs-v2 (was Re: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...))

From: Suresh Krishnan <[email-masked]>
Date: Thu, 07 Sep 2006 19:27:18 -0400

Since I have not heard any objections to Bob's mail after a week, I 
assume that the WG is fine with the change. I will replace the first 
paragraph of section 2.4 with the following text

One way to avoid having a static non-changing address is to use
DHCPv6 [DHCPV6] for obtaining addresses. Section 12 of [DHCPV6]
discusses the use of DHCPv6 for the assignment and management
of "temporary addresses", which are never renewed and provide the
same property of temporary addresses described in this document with 
regards to the privacy concern.

Cheers
Suresh

Bob Hinden wrote:
> Pekka,
> 
> On Aug 31, 2006, at 6:18 AM, Pekka Savola wrote:
> 
>> On Thu, 31 Aug 2006, Ralph Droms wrote:
>>> Suresh - I think Jinmei-san and I have come to agreement on 
>>> replacement text
>>> in section 2.4 (see below).
>>
>> As a WG participant, if we want to go ahead with the change, I'd 
>> expect WG chairs to issue a last call of some sort for the changes 
>> (giving a good motivation for the change), given that the document has 
>> already left the WG quite a while ago.
>>
> 
> The chairs believe these changes are editorial in nature and don't 
> require another working group last call.
> 
> That said, if anyone has any objections to the proposed changes please 
> speak up.
> 
> Bob Hinden / Brian Haberman
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 8 Sep 2006 16:51:41 -0400

RFC 791 (IPv4) Appendix B gives clear instructions on the byte
transmission sequence to be used in IPv4, both in the IP headers and in
the payload. Since RFC 793 (TCP) does not reiterate this info, my
presumption is that RFC 793 relies on RFC 791. Left to right byte
transmission sequence, big endian for binary quantities.

Checking into RFC 2460 (IPv6), I see no counterpart to RFC 791's
Appendix B, but I also see no mention of dropping this endianness
instruction intentionally, up in Section 1, where the changes wrt RFC
791 are summarized. Which now leaves a loose end wrt TCP and other upper
layers.

Browsing the I-Ds and other promising RFCs did not help (although I
didn't read all thoroughly). I checked RFC 1883 to see if perhaps
endianness was previously specified and then dropped.

Have I missed something, or was this info deleted because it's too
inflammatory?

Thanks.

Bert

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 08 Sep 2006 23:24:54 +0200

Manfredi, Albert E wrote:
[..]
> Have I missed something, or was this info deleted because it's too

Nope. As far as I know of, in the case of all IETF protocols, "Network 
Byte Order" is always used, and this means Big Endian. Thus when Little 
Endian is supposed to be used, it will always have to be specified, 
otherwise it is per default Big Endian.

Greets,
  Jeroen

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 8 Sep 2006 17:49:07 -0400

> otherwise it is per default Big Endian.

Thanks for the replies, Jeoren and Fred. But this non-specification
leaves me with a problem.

Rightly or wrongly, in the past when some folk tried to create TCP or
UDP messages with little endian ordering in the payload, I could steer
them on the path of righteousness with a simple mention of RFC 791.
Evidently, many find that Appendix B to be "draconian," but it would
still usually end all discussion.

Now there seems to be no guidance, even less "draconian" than RFC 791,
for headers or data.

I guess we'll just have to go with "Internet convention" arguments.

Bert

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 09 Sep 2006 00:09:46 +0200

> I guess we'll just have to go with "Internet convention" arguments.

Well we can also go the Wikipedia route:
8<---------------
Networks generally use big-endian numbers as addresses; this is 
historically because this allowed the routing to be decided as a 
telephone number was dialed. Motorola processors have generally used 
big-endian numbers, and ARM processors gained truly switchable 
endianness in order to improve performance of networking devices based 
on them.
---------------->8

and more importantly:
8<------------------
The Internet Protocol defines a standard "big-endian" network byte 
order. This byte order is used for all numeric values in the packet 
headers and by many higher level protocols and file formats that are 
designed for use over IP.
-------------------->8

convincing is also:
8<-------------------
The Berkeley sockets API defines a set of functions to convert 16- and 
32-bit integers to and from network byte order: the htonl and htons 
functions convert 32-bit ("long") and 16-bit ("short") values 
respectively from host to network order; whereas the ntohl and ntohs 
functions convert from network to host order.
-------------------->8

If Internet Protocols where not usually/always in Big Endian format, 
then those functions would not have existed.

Greets,
  Jeroen

---

From: Elwyn Davies <[email-masked]>
Date: Sat, 09 Sep 2006 03:12:06 +0100

After a little detective work:

The concept of a 'standard' (Internet) network byte order appears to 
have crept into the RFC series without actually officially linking 
Appendix B of RFC 791 (dated Sptember 1981) to the term.

AFAICS the earliest use of the term 'standard network byte order' is in 
RFC951 which defines BOOTP and appeared in September 1985.

Also the BSD networking code provided the various network-to-host and 
host-to-network conversion functions/macros 2 or 3 years earlier.

Arguably, network byte order is crystallized forever by Danny Cohen's 
IEN 137 "On Holy Wars and a Plea for Peace" (April 1 1980 ;-) ) which 
sanctified the terms 'Big-endian' and 'Little-endian' for computer 
addressing architectures and effectively expressed a preference for 
using Big-endian for network transmssion order (but the term network 
byte order is not used).

As regards the assumption of 'standard network byte order' in IPv6 is, I 
guess, implicit in
1. The reference to RFC 791
2. The view that IPv6 is an update of IPv4 such that the beginning of 
the IP packets allow you to distinguish packets of different IP versions 
when they are on the same wire.  Arguably that would not happen if the 
network byte/bit orders were different.
3. The many (tens? hundreds?) of RFCs between 791 and 1883 and since 
that explicitly mention (standard) network byte order.

Maybe somebody ought to write a very short I-D just to set the record 
straight.

/Elwyn

Jeroen Massar wrote:
> ------------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Sep 2006 10:03:16 +0200

There are multiple references to network byte order in RFC 3542,
and it's very specific for raw sockets. That seems clear enough.

RFC 1958 says:

    3.13 All specifications should use the same terminology and notation,
    and the same bit- and byte-order convention.

(sadly, without saying what it is...)

There really doesn't seem to be any scope for doubt here.

     Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 10 Sep 2006 19:00:25 -0400

> There really doesn't seem to be any scope for doubt here.

Thanks for the parenthetical levity, Brian.

Unfortunately, 3.13 is somewhat confusing too, because by mentioning bit
order, which is clearly different among link layers, it implies that the
"convention" mentioned only applies to how bits and bytes are shown in a
diagram. Not what the transmission sequence of bits or bytes ought to
be.

Clearly, for example, the MSbit is sent first in FDDI, last in Ethernet.
And yet the MSbit is always shown on the left and numbered Bit 0 in
Internet convention. But byte transmission order is a different matter.
Typically, MSbytes are shown on the left *and* are transmitted first.

(Not that I want to second-guess what you intended in that RFC.)

I can certainly accept the idea that in 1981, when RFC 791 was written,
there was no preference for big endian byte transmission order.
Certainly not in DoD interface standards of the time, which I'm sure
DARPA was well aware of. By now, it *should* be common knowledge. But I
emphasize should for a reason.

Thanks again.

Bert

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Sep 2006 09:25:29 -0700

Elwyn,
 
> Maybe somebody ought to write a very short I-D just to set the record 

It looks like there was at least one attempt to do that; see:

http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-newman-netw
ork-byte-order-01.txt

I don't know the status of this effort, and I don't know whether
there would be support to revive it. But, this subject seems to
to fall within the auspices of the (unwritten) "IETF Reference
Architecture".

I sent a note to the IAB a while back asking why there wasn't
a "Terminology of the IETF" reference document (i.e., one that
defines common terms like "link", "node", "host", "router",
etc.). But, the more I think about it, the more I think that
this would be counter-culture to the way the IETF works.

IMHO, the "IETF Reference Architecture" exists, but it
is documented in a "bottom-up" fashion and is fragmented
across the standards-track RFCs. To bring the fragmented
pieces into a single document that captures the IETF
architecture would seem like a worthy goal, but would
it be acceptable to the "Tao" of the IETF?

Do we need a more detailed and unified "IETF Reference
Architecture" document, or are existing documents like
RFC1958 enough?

Fred
[email-masked]

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 11 Sep 2006 18:30:45 +0200

Templin, Fred L wrote:
[..]
> Architecture" document, or are existing documents like

This more looks like a call for an "IETF Encyclopedia" or a FAQ... which 
thus nowadays would mean a Wiki ;) Especially with many terms considered 
to be moving targets, extensions being made etc. it might be handy to 
have such a set of pages, but they should be linked into the existing 
information resources. Sounds like a job for the overly busy Tools team 
to me.

Greets,
  Jeroen

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 11 Sep 2006 20:44:32 +0100

> http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-newman-netw
I think Chris Newman probably works for Sun now.  It appears he is 
active in sasl.

I think the document needs a discussion/reproduction of the stuff in 
Appendix B of RFC 791.

I would be willing to take on updating this doc if Chris doesn't want to 
follow through.
> this would be counter-culture to the way the IETF works.
I guess there are several different classes of item to consider
- the common terms could well be defined in a wiki - pointing at 
relevant RFCs
- there are some fundamental design decisions such as the network byte 
order (what else?) which should IMO have RFCs
- there are architectural principles - it is probably about time 
somebody took a critical look at RFC 1958 to check it is still up to 
date - maybe Brian does this already!
- BCP type advice on how to design certain critical things (generally 
done as IAB pronouncements) - opinions on missing important ones 
gratefully received!
> Architecture" document, or are existing documents like
Interesting question.  Have to think what might go into it.

Regards,
elwyn

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Sep 2006 08:21:55 -0700

Elwyn,

> I would be willing to take on updating this doc if Chris doesn't want
to 

FWIW, I would support your taking the lead on this effort.

Fred

---

From: Bob Hinden <[email-masked]>
Date: Wed, 13 Sep 2006 11:15:30 -0700

Folks,

In my personal view, while this is a nice theoretical problem, no  
evidence has been presented that anyone building an implementation is  
confused about it.  For example, were there ever any interoperability  
problems because someone did this wrong?  Common sense would indicate  
that IPv6 has the same "endianness" as IPv4.

I have hard time understanding why documenting this further this  
would be a good use of anyone's time (i.e., individuals, IPv6 w.g.,  
ADs, IETF, RFC-Editor, ....).

Bob

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 13 Sep 2006 15:26:02 -0400

> ADs, IETF, RFC-Editor, ....).

Bob, since I brought this up to the wg, I'd like to say that this has
been an issue repeatedly. In one case, interoperability problems existed
already, when one organization decided to use little endian in certain
variables of a multicast message (for navigation data). Fortunately,
they corrected the problem rather than force everyone else to comply.

But in several other cases, the question "will this be big or little
endian?" has come up, and I had this handy-dandy RFC 791 appendix to use
to put an end to the discussion. This has happened over the years, the
most recent examples being just weeks ago. So yes, it's an ongoing
problem.

Not everyone out there who writes IP applications is familiar with IP
conventions. These aren't necessarily people who write applications for
the office or the WWW. And it is very difficult to convince those who
already "have all the answers," and whose processor today may be a
little endian machine, that really in the bigger perspective they're
better off using the industry standard.

As we are migrating to IPv6, the same questions will continue to come
up. And as of now, other than referring people back to an RFC written
for IPv4, or to a Wikipedia article kindly pointed out by Jeroen, there
is nothing in writing to give any guidance for IPv6.

Bert

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Sep 2006 21:26:39 +0200

On 13-sep-2006, at 20:15, Bob Hinden wrote:

> evidence has been presented that anyone building an implementation  
> is confused about it.  For example, were there ever any  
> interoperability problems because someone did this wrong?  Common  
> sense would indicate that IPv6 has the same "endianness" as IPv4.

> ADs, IETF, RFC-Editor, ....).

Well, I think it's a pretty big oversight that this was never  
standardized in any of the IPv6 RFCs. Now obviously there are many  
interoperable implementations so it doesn't matter in the real world,  
but that's no reason to let this slide.

I can tell you from experience that showing up for interop testing  
after implementing some specification and seeing that the other side  
uses the opposite byte ordering is no fun. And then arguing with the  
people who wrote the spec about whose interpretation is the correct  
one is even less fun.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 15 Sep 2006 17:11:30 -0400

> ADs, IETF, RFC-Editor, ....).

Let's see. If an implementor got this wrong, and actually tested their
implementations with one of the bazillion IPv6 implemenations or test
suites (some productized and some nearly 10 years old -- and all of
them seeming to do the same thing w.r.t. network byte order), and
there was a subsequent dispute about who was right and needed to
change their implementation, would anyone care about what was (or was
not written) in an RFC on this point?

I didn't think so. :-)

Thomas

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 15 Sep 2006 23:26:58 +0200

> not written) in an RFC on this point?

On the other hand, is it good for a standards organization to leave  
important technical details unspecified and assume tradition and  
interoperability testing will take care of the difference?

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 15 Sep 2006 17:24:48 -0400

> not written) in an RFC on this point?

Bazillion IPv6 implementations?

What if a vendor writes the application and tests it with one other
vendor's software. The application does not work. And the decision now
has to be made as to which vendor needs to fix the problem?

This is in a lab, before deployment, before many other vendors start
writing their own code to make use of this message. Add to the mix that
the decision makers, those who determine who gets to make the fix, are
almost certainly clueless as to any conventions in IP that we're all
supposed to take for granted.

In IPv6, how does one convince the decision maker to do the right thing?
This happens in real life. It's not just an improbable scenario. And
keep in mind that the first vendor is being very defensive by now.

Bert

---

From: "Eric Klein" <[email-masked]>
Date: Sat, 16 Sep 2006 13:21:53 +0300

> interoperability testing will take care of the difference?
I think not, real question is do we want implicit or explicit standards? I 
vote for explicit

---

From: Pekka Savola <[email-masked]>
Date: Sat, 16 Sep 2006 20:13:40 +0300 (EEST)

> I think not, real question is do we want implicit or explicit standards? I 

No, the real question is, "how do we want the spend the time and 
energy in the IETF?", in other words, is this obvious enough that 
making explicit guidance isn't worth our time (as there is probably a 
lot of other things that the IETF and its participants could be 
doing).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Thomas Narten <[email-masked]>
Date: Mon, 18 Sep 2006 09:07:41 -0400

Jeeze, I find it hard to believe some people seem to think this is a
serious issue!!!

> Bazillion IPv6 implementations?

Certainly in the 20-100 range, depending on how you count the
genetics. Point is, many implementors have implemented IPv6, and as
far as anyone here can tell, nobody had a question about endianness
before, or if they did, they figured out the answer plenty quick
without coming to the IETF for clarification. Conclusion: this is not
a real problem in practice.
 
> has to be made as to which vendor needs to fix the problem?

Any competent implementor would then ask "what is the history of this
other software I'm testing against? Is it well-known? Are people using
it? Have they tested it?" Etc.

The idea that two implementations (implemented from scratch) and not
tested with an existing well-known one first, would test against each
other and then point fingers at each other when the spec clearly does
not say which interpretation is right seems just silly!

> writing their own code to make use of this message.

Let's be real. Anyone doing an implementation from scratch from the
specs would (with high probality) do its first test against a
well-known, readily available implementation. E.g., linux, *BSD, or
any of the available products. (Well, if they thought about what they
were doing for any length of time, anyway)

> In IPv6, how does one convince the decision maker to do the right

Does common sense play any role here? (I know, a lot to ask...)
  
> keep in mind that the first vendor is being very defensive by now.

OK, if there is a real vendor that did the endinness wrong, go ask
them to test against the Microsoft stack (or Sun, or IBM, ...) And if
they then think those vendors all got it wrong, have them come back to
the IETF and show where in the relevant RFCs there is wording to
support their interpretation. There is a big difference between "not
clearly specified, and hence my interpretation could be wrong" and
"the spec says Y, therefore the other vendors interpretation to do Z
instead is wrong"

And note, I'm not saying this oversight is a good thing or
"right". Its clearly an oversight. Next time we revise the relevant
spec, clarifying wording should go in. But is this such a problem that
a separate RFC should be written just to clarify this point? Please! I
thought the IETF had real work to do with its limited cycles.

Next challenge (for those with time on their hands). How many other
IETF specs neglected to explicitely state the endianness of protocols?
(My prediction, a rather lot of them.) Followup: has it caused great
problems in practice? I'd bet not. It may have caused problems in some
cases, but I suspect not in a lot relatively speaking.

Thomas

---

From: Brian Haley <[email-masked]>
Date: Mon, 18 Sep 2006 12:17:02 -0400

Thomas Narten wrote:

> any of the available products.

They'd run the TAHI/IPv6ready Logo tests, fail miserably, and fix their 
implementation.

I've been to many, many bake-offs from Connectathon to ETSI for IPv6 and 
Mobile IPv6, and haven't seen any endian issues at them, so I really 
don't think this is an issue either.  I wouldn't be opposed to a 
one-sentence RFC saying "network byte order/big endian is assumed in all 
RFCs unless otherwise noted" if it will stop this thread :)

-Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 18 Sep 2006 16:14:38 -0400

> Does common sense play any role here? (I know, a lot to ask...)

No, not in your sense. The "common sense" that plays a role is one which
asks, "What is the cheapest fix, short term?"

How hard would it be, for example, to include words similar or identical
to RFC 791 Appendix B in RFC 2460bis? Or to revive the old I-D we saw
that mentions this topic, keeping it as an independent RFC?

Unless, of course, people now find that Appendix B to have been a
mistake.

> problems in practice? I'd bet not.

Again, it has caused me problems. One of intererability, and the others
of having to continue to remind people of RFC 791 Appendix B.

The simple fact is, in IPv6 we no longer have that clear statement to
use.

Bert