Subject: Use of IP6.INT

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Jan 2000 15:02:23 -0800 (PST)

[Retransmitted with correct email for the ipng list.]

Please followup on the ipng list only.

There has been some discussion for a while in the IAB and IESG about the
use of .INT. Since this is assigned to ITU to do assignments for
international (treaty?) organizations it is clear that the IETF should
not use .INT for any future use.

The question on the table is whether or not we should switch IP6.INT
to be somewhere else. I'd like to understand the implications of
doing such a switch and in particular it it can be piggy-backed on
the transition from AAAA to A6, DNAME, and binary labels.

There seems to be consensus that .arpa would be a good place to put
things like the IPv6 reverse tree since it already contains
the IPv4 reverse tree. If we go this path we should presumably invent a new
meaning for .arpa. So far I've seen two good suggestions:
	Address Reversing Pointer Access
	Address and Routing Parameters Area

Thus ip6.arpa (or in6-addr.arpa if you want it to be closer to in-addr.arpa)
could be a reasonable domain to use.

Transition:
Looking at the draft-ietf-ipngwg-dns-lookups draft and the binary 
labels RFC (RFC 2673) there already seems to be a transition for 
reverse lookups, althought it isn't explicitly mentioned in dns-lookups draft.

The old AAAA spec says to look in IP6.INT by making a (text) label out of each
nibble and reversing the order.
In the new dns-lookups spec says to look in IP6.INT for a binary label 
consisting of the whole IPv6 address. This can be viewed as 128 one bit 
labels in reverse order. Note that RFC 2673 clearly says that a binary label 
never matches an ASCII label "0" and "1".
Thus for transition purposes it seems like the reverse lookup, just like 
the forward lookup trying A6 and AAAA in some order,  need to try two
different lookups in some order.

Thus it might be realatively painless to make the new way also look in
a different place; such as ip6.arpa instead of ip6.int.

Comments?
   Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 25 Jan 2000 17:18:21 -0600

Erik,

It looks perfectly fine to me.

			Matt

---

From: Bob Halley <[email-masked]>
Date: 25 Jan 2000 16:09:21 -0800

> different lookups in some order.

Yes.  At least in the first beta, BIND 9 will try the bitstring label
scheme first, and then it will try the nibble scheme.  (A future
release may allow the search order to be changed).

> a different place; such as ip6.arpa instead of ip6.int.

Are you suggesting looking in a third place?  We can do this, but I'd
rather not have to.

/Bob

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 26 Jan 2000 09:09:11 -0600

> Are you suggesting looking in a third place?  We can do this, but I'd

$ORIGIN IP6.INT.
\[b0]	9999999	IN	DNAME	\[b0].IN6-ADDR.ARPA.
\[b1]	9999999	IN	DNAME	\[b1].IN6-ADDR.ARPA.

Would that help the transition, or just slow it down?

				Matt

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 26 Jan 2000 14:19:39 -0800 (PST)

> Are you suggesting looking in a third place?  We can do this, but I'd

No. I'm assuming that, if we decide to do this change, we can do it 
quickly enough that there will be no (or close to zero) bit string labels
in the ip6.int tree so we can just swap that part to instead look in
ip6.arpa.

Thus BIND would (in some order) look for reversed nibbles in ip6.int
and bit string labels in ip6.arpa.

   Erik

---

From: Thomas Narten <[email-masked]>
Date: Fri, 28 Jan 2000 08:38:52 -0500

Here's a bit more background on the desire to move away from ip6.int
(or rather for moving away from .int period).

It has been pointed out that that we may not want to use .INT for
basic infrastructure. The concern is that mingling infrastructure
domains with the "treaty organization" primary function of .INT will
sooner or later cause problems, even though ITU is being very careful
and cooperative about our views today. Note that the overall plan for
.int is that ITU is the organization that will manage it.  Even if no
problems ever arise, the combination exposes the IETF to more
complaints about selling the Internet to the ITU. Thus, it seems
prudent to consider using some other domain instead of .int, if the
cost of switching is acceptable.

Indeed, the IAB has requested that the IESG review all uses of .int to
see if it is feasible to switch them to some other domain. Obviously,
it won't make sense to switch every use, and the cost/benefit needs to
be considered on a case-by-case basis. That is where the current
question comes up.  We are at a point with IPv6 where we have an
opportunity to make such a switch. If we don't do so now, we never
will. Thus, we should consider the ramifications of such a switch and
whether the cost of switching justifies the benefits.

There is a bit of an operational issue here. ip6.int (or whatever the
top part of the domain name) needs to be reliable and stable
operationally. It will be part of the basic infrastructure and there
should be no question about its working in practice.

Why .arpa?

Ideally, picking a new TLD just for basic infrastrucuture would seem
the way to go. But dealing with the political and social issues that
go along with creating new TLDs at this time makes this choice
unattractive.

We also want something short (i.e., as few components removed from the
root as possible), so subdomains off of (say) ietf.org would not be
ideal. Plus, it's not clear that CNRI wants to take on such a
responsibility.

That leads to .arpa. We have running code that it is stable and works
(the in-addr.arpa part of the namespace, not necessarily the
registration of individual addresses).

I view this as a chance to buy a bit of insurance. The cost upfront
seems quite small (based on discussion so far), but the potential
payoff could be large.

Thomas

---

From: Jim Bound <[email-masked]>
Date: Fri, 28 Jan 2000 09:33:43 -0500

Thomas,

You did not address the need in the interim to support IPv6.INT until
next generation products can use .arpa or whatever.

You say its minimal.  Its not.  We do not want to send out patches with
our first releases of Ipv6.

You ignored all that mail in your response. 

Also continually in IPv6 trade-offs as an AD you keep saying we can make
the change the pain is minimal.  Lets get this straight we are deploying
IPv6 and any change that affects shipping software is NOT MINIMAL
ANYMORE.

Besides it sounds like its really not the IETFs decision to blow
ipv6.INT away.  

I am already speaking offline with others and there is a political issue
here too.  If I do not see the IETF support the issues raised by Bill
Manning and several implementors on this list we will use our own
implementors lobby with the ITU or ICANN to protect our investment.

Is that what you want?

The IETF has to sometimes do what the implementors want.  

And don't bullshit us.  The IETF and ITU don't get along and the IETF is
very nervous about the new power of the ITU via ICANN.  Lets not appease
any needs the IETF has by throwing a sacrifical lamb being IPv6.

Also I think its time the vendors started lobbying their interests
wherever to make sure the Internet infrastructure is not routed with
phone numbers etc. via ITU thought processes.  The IETF is a great
STANDARDS BODY.  But quite frankly the vendors and consumers have a
great interest in the Internet staying the way it is and moving forwared
into the next millenium.  I don't the IETF is the org to influence and
put pressure on the political processes to cover our butts.  I think we
need more powerful and connected leadership to keep our interests in
tact.

Fine to make a recommendation.  But you should stay out of the business
of keeping the Internet running or start working with the vendor
community.  Maybe this is an Internet Society issue.

The IETF is simply not qualified to WIN the political battle.

There are folks on the IESG and IAB who are qualified but the fact that
they are having to play the social and consensus game of the IETF is
probably holding them back from fixing the root issues of stewardship of
the Internet.

regards,
/jim

---

From: Bill Manning <[email-masked]>
Date: Fri, 28 Jan 2000 07:41:02 -0800 (PST)

% 
% Here's a bit more background on the desire to move away from ip6.int
% (or rather for moving away from .int period).
% 
% It has been pointed out that that we may not want to use .INT for
% basic infrastructure. The concern is that mingling infrastructure
% domains with the "treaty organization" primary function of .INT will
% sooner or later cause problems, even though ITU is being very careful
% and cooperative about our views today. Note that the overall plan for
% .int is that ITU is the organization that will manage it.  Even if no
% problems ever arise, the combination exposes the IETF to more
% complaints about selling the Internet to the ITU. Thus, it seems
% prudent to consider using some other domain instead of .int, if the
% cost of switching is acceptable.

	Thanks for the background data.  Is this from you or from
	someone else? Some of the precepts and assumptions in this
	background material seem questionable, e.g. the existance
	of an "overall plan", and the ability of the IETF to "sell"
	the Internet to the ITU, (or anyone else for that matter).

	Migrations are lengthy and have many costs.  This material
	argues that we should abandon the attempts to migrate away
	from the .arpa zone, which has been in process for ~15 years
	and now abandon the infrastructure zone which was earmarked
	by the IANA as the place to migrate to. 

	It almost seems that the IETF is attempting to co-op culpability
	for potential political ramifications that rightfully are ICANNs
	turf.  IANA/ICANN gave us the .INT zone for infrastructure.
	Should we turn it down because we think it might be politically
	sensitive?  I think this is a bit beyond IETF perview.

--bill

---

From: Thomas Narten <[email-masked]>
Date: Fri, 28 Jan 2000 11:35:10 -0500

> 	the Internet to the ITU, (or anyone else for that matter).

This comes from folks other than me that know more about this
space. I.e., the IAB discussed this and felt sure enough about their
facts to make a recommendation. I will try and get someone else to
comment directly.

> 	by the IANA as the place to migrate to.

There is actually a plan to migrate away from in-addr.arpa?

> 	turf.

No. The IETF is trying to avoid a potential problem that may impact
the Internet. Why is it ICANN's decision what domain names we use? We
choose, based on what we think our our interests.

> IANA/ICANN gave us the .INT zone for infrastructure.

I think what is at issue is who is "us". My understanding is that .int
will go (if it is not officially so now) to ITU. IETF is not ITU. :-)

> 	sensitive?  I think this is a bit beyond IETF perview.

The issue isn't whether this is politically sensitive. The issue is
whether the IETF feels that there are technical or operational
ramifications with continuing to use ip6.int. There would appear to be
a potential issue here, so why not just remove that potential, assuming the
cost is low enough?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 28 Jan 2000 11:47:55 -0500

Jim,

> next generation products can use .arpa or whatever.

The proposal on the table is to continue to use ipv6.int for the
existing AAAA records. No change to shipping code in that
regard. Indeed, I would expect that ip6.int wouldn't ever go away. It
would just at some point stop being used, as everyone moves to A6.

.arpa (or whatever it is) would be used for the NEW A6 records, or
rather, for implementations that understand A6, bit string labels and
the like. These have not been deployed, and the code for implementing
A6 is still being finalized. (At least that is my understanding of the
state of A6 implementations.)  So it does seem to me that it is
relatively painless to have all the A6 based stuff use .arpa while we
continue to use ip6.int for the existing standards (and products).

No need for a flag day. The goal of A6 is to eventually phase out AAAA
once it is widely deployed. Once that happens, everyone presumably
will be able to just use .arpa.

> our first releases of Ipv6.

I'm very concerned about not making changes to IPv6 at this point that
impact products and deployment. That's the purpose of the thread --
evaluate whether this is feasible.  My understanding of the messages
that have been posted is that the change is fairly minimal. I don't
understand why you think you need to send out patches in your first
release, but didn't mention that in my previous note as Erik (I think)
raised that exact question in a separate note.

> Also continually in IPv6 trade-offs as an AD you keep saying we can
> make the change the pain is minimal.  Lets get this straight we are
> deploying IPv6 and any change that affects shipping software is NOT
> MINIMAL ANYMORE.

I don't understand how this impacts shipping code. As Erik pointed
out, this does not change RFC 1886 at all, which is what I presume
everyone is shipping. 

> Besides it sounds like its really not the IETFs decision to blow

Sure, not our decision to "blow away" ip6.int. But it IS our decision
whether we choose to use the domain name. Our specs are the ones
saying use "ip6.int". We can change our specs to use some other domain
name.

> here too.

Sure, there is a bit of a political issue here. Please note that the
concern is that political issues might someday have a real (negative)
operational impact. That wouldn't be good for IPv6 deployment.
If the possibility can just be removed, why not do so?

> If I do not see the IETF support the issues raised by Bill Manning
> and several implementors on this list we will use our own

The purpose of this mail thread is to decide whether the WG wants to
make this change or not. If the IETF does not support the change, of
course it won't be done.

> The IETF has to sometimes do what the implementors want.

Of course!

> And don't bullshit us.  The IETF and ITU don't get along and the
> IETF is very nervous about the new power of the ITU via ICANN.

My take is that the IETF isn't nervous about the "new power" of the
ITU. Rather, our concern is that various standards organizations
(including the ITU) have discovered the internet and want to assert
influence over that space precisely because that is where the action
is. The IETF's view is "we are doing just fine thank you, we don't
need help in areas where we have demonstrated core competency". I.e.,
if you want to help, just come to the IETF and go directly to our
WGs. Looking at a concrete example, the IETF is now having to do a
certain amount of damage control where other standards bodies are
attempting to do work in areas that are clearly IETF turf. Do you want
the ITU to start doing standards work on IPv6?  Well, they just happen
to be trying to do some work that conflicts directly with PPP over
Sonet, and that we think is totally unnecessary (actually, we believe
it will be harmful to the community because it sends confusing signals
to the marketplace and would likely cause vendors to have to implement
two different standards where one suffices).

> Lets not appease any needs the IETF has by throwing a sacrifical
> lamb being IPv6.

IPv6 is not a "sacrificial lamb" here. If this change can be done
without much pain, let's do it. If it can't, let's not.  The whole
point of this excercise is to eliminate a potential negative issue to
IPv6 deployment.

> need more powerful and connected leadership to keep our interests in

Again, the entire point of the proposed change of ip6.int -> .arpa is
to remove a potential political aspect from the picture. That way we
won't ever have to fight a battle on this particular issue.

Thomas

---

From: Bill Manning <[email-masked]>
Date: Fri, 28 Jan 2000 08:52:44 -0800 (PST)

% > 	Migrations are lengthy and have many costs.  This material
% > 	argues that we should abandon the attempts to migrate away
% > 	from the .arpa zone, which has been in process for ~15 years
% > 	and now abandon the infrastructure zone which was earmarked
% > 	by the IANA as the place to migrate to.
% 
% There is actually a plan to migrate away from in-addr.arpa?

	Sure.  There used to be hosts & second-level zones under the
	.arpa space.  Most of it was emptyed out by the early/mid
	90's.

% > IANA/ICANN gave us the .INT zone for infrastructure.
% 
% I think what is at issue is who is "us". My understanding is that .int
% will go (if it is not officially so now) to ITU. IETF is not ITU. :-)

	Back in the mists of time, My memory is the 1996 IETF held w/
	ISOC in Montreal, there was a discussion on where to home the
	inverse data for the IPv6 protocol.  The IANA (Postel) thought that 
	moving things into the INT heirarchy made the most sense
	and both the ip6.int and an ip4.int zones were created.  
	There was some kickback from ISC on the difficulties in
	changing the installed resolver base to look in the int zone
	for ipv4 resolution, so in-addr.arpa is still around.
	Hope that clarifies the "us" part, e.g. the code developers
	and operators that were concerned about the issue.  I think
	this was mentioned in at least one of the IPv6 working groups
	at the time, but may have been overlooked as there were still
	many protocol issues outstanding and this was considered too
	operationally mundane.

	You are hearing more about this very issue now from both Bob Halley
	and Jim Bound.  As to the future of the .INT zone, your 
	understanding and mine appear to differ.  The existant reality
	is that .INT is under ICANN control.  The future of any zone
	is open for debate.

% > 	Should we turn it down because we think it might be politically
% > 	sensitive?  I think this is a bit beyond IETF perview.
% 
% The issue isn't whether this is politically sensitive. The issue is
% whether the IETF feels that there are technical or operational
% ramifications with continuing to use ip6.int. There would appear to be
% a potential issue here, so why not just remove that potential, assuming the
% cost is low enough?

	There are technical, operational, and political ramifications
	for the use of -ANY- zone. 
% 
% Thomas
% 

-- 
--bill

---

From: Jim Bound <[email-masked]>
Date: Fri, 28 Jan 2000 20:28:36 -0500

Hi Thomas,

>would just at some point stop being used, as everyone moves to A6.

Well we can move to the new "literal" if it is to be we just need time to
synch up with a release of BIND that will be using the new one.  We
probably should stop hardcoding this but that will take some software
analysis I can't say its simplistic.

>continue to use ip6.int for the existing standards (and products).

For A6 yes.

>will be able to just use .arpa.

Does that mean the Internet would host an ip6.int zone for some time?

>raised that exact question in a separate note.

When an app does getnameinfo(3ffe::9) it results in a query for the
nibble value of the address ip6.int.  This is all hard coded in the APIs
usually at the resolver.  If ip6.int went away as a zone and became
ip6.arpa the software would break. To fix it we would go in and change
all ip6.int's to ip6.arpa and send out a patch to all users of a certain
release.  I don't want us or other vendors to have to do that. We need a
grace period to move to ip6.arpa.

But if ip6.int will not go away then that is not a problem and I agree
it will just phase out.

But I took the mail to say ip6.int will disappear off the Internet not
just in the specs.

>out, this does not change RFC 1886 at all, which is what I presume

I think I explained that above.  Also I should not shoot the messenger
here but your wearing the IESG hat as is Erik. It just seems around 
here that I don't think folks realize for some of IPv6 it cannot be a
free for all change if we have deployed and built/shipped it.  But I
could be over-reacting I will admit.  Rather do that than risk that IPv6
is ill-affected.  Sorry.

>saying use "ip6.int". We can change our specs to use some other domain

Agreed.  Been good if that was in the first mail.

>If the possibility can just be removed, why not do so?

But there is a systemic problem with the ITU and ICANN.  But I agree if
fixing this one is just blow it away then do it.  In this case.

>two different standards where one suffices).

The ITU can be dealt with but you need to use a large political hammer
and right now the IETF don't have one, except the technical argument. I
say you cannot win these various skirmishes with technical arguments.
You have to apply extreme pressure to places that cause pain sometimes
to get entities to listen.  A big hammer is really good because you just
have to swing it once and land it as it covers a lot of area and has a
large mass.  The recipient will be stunned so that the next time they
do battle with you they will have respect, then your negotiating
position is much better.  As a user of the Internet I don't want to
happen the kind of things you describe above.  I think on the IAB and
IESG there are some very good politicians in the ranks and can apply the
tactics to win a battle with entities like the ITU or ETSI. But overall
I don't believe the IESG or IAB have that skill-set as a "group".
What we need maybe is a group of pitt-bull dogs under the ISOC or maybe
under some supportive Govt Agency that will let the pitt-bull dogs out
of their cage when an entity cannot see or won't listen to the
technical arguments which are in the best interest of the Internet (that
I do believe the IESG and IAB are good at if they work with the
implementors when it gets to the details).

regards,
/jim

---

From: Bill Manning <[email-masked]>
Date: Fri, 28 Jan 2000 23:43:50 -0800 (PST)

% Hi Thomas,
% 
% >> You did not address the need in the interim to support IPv6.INT until
% >> next generation products can use .arpa or whatever.
% >
% >The proposal on the table is to continue to use ipv6.int for the
% >existing AAAA records. No change to shipping code in that
% >regard. Indeed, I would expect that ip6.int wouldn't ever go away. It
% >would just at some point stop being used, as everyone moves to A6.
% 
% Well we can move to the new "literal" if it is to be we just need time to
% synch up with a release of BIND that will be using the new one.  We
% probably should stop hardcoding this but that will take some software
% analysis I can't say its simplistic.

	So technically it can be done, if there is coordination between
	all parties. I still don't have a good feeling as to -why-
	the IAB thinks this is worth the effort unless ICANN has 
	announced it will transition the .INT zone to ITU.

	Doing this simply because it -might- look better does
	not argue that .arpa. is better.  Will the IAB state
	with assurity that DARPA will never want its zone back?

	I'd really like a reading on this from the ICANN staff
	before we get too far down the path of, 'ah, I guess that
	the IAB thinks this is the best place to home the zones...
	this year.'  We (operations and developers) were pointed
	into the .INT zone by the IANA as a way to vacate the
	.ARPA zone.  I think we should get some direct comment
	from them.       

% Does that mean the Internet would host an ip6.int zone for some time?

	Yes. One more legacy point for inverse lookup. Jumping to a
	third w/o an active plan to migrate away is asking for
	a decade plus of using the ip6.int zone anyway, regardless
	of where it sits.

% I don't want us or other vendors to have to do that. We need a
% grace period to move to ip6.arpa.
% But if ip6.int will not go away then that is not a problem and I agree
% it will just phase out.
% But I took the mail to say ip6.int will disappear off the Internet not
% just in the specs.

	Thats the perceived threat. The ITU will get the .INT zone and
	not respect grandfathered delegations.  I really want the IAB
	to back this assertion with a statement by the IANA that they
	are going to hand the .INT zone to ITU  and a statement that 
	DARPA will quit-claim on the .arpa. zone for the IABs use
	before we wander too far down the path of fabricating alternate
	solutions.  Just "phasing out" will take a very long time.

% >Sure, not our decision to "blow away" ip6.int. But it IS our decision
% >whether we choose to use the domain name. Our specs are the ones
% >saying use "ip6.int". We can change our specs to use some other domain
% >name.

	But why should we? 

% The ITU can be dealt with but you need to use a large political hammer
% and right now the IETF don't have one, except the technical argument. I
% say you cannot win these various skirmishes with technical arguments.

	Since we were told by the IANA that ip6.int is/was ok, 
	I wonder why the IAB has decided that its not OK and we
	as operators and developers should start second guessing
	IANA and believe them on a potential political debate?

% regards,
% /jim

---

From: Jim Bound <[email-masked]>
Date: Sat, 29 Jan 2000 22:34:56 -0500

All good points bill.    

/jim

---

From: Thomas Narten <[email-masked]>
Date: Mon, 31 Jan 2000 14:25:55 -0500

> 	announced it will transition the .INT zone to ITU.

I've seen little from the ICANN story to date that gives me a warm
cozy feeling. You have a crystal ball as to what ICANN really will or
will not be doing with the .INT zone? Whether ICANN thinks they need
to make such a transition or not misses the point. There is a real
concern that they will be forced to transition .INT elsewhere under
outside pressure from folks who think ICANN has no business hosting
TLDs. I.e, there are forces at play here over which we have zero
influence.

> 	But why should we?

Cheap insurance to avoid the possibility of a far more major hassle
later.

> 	Since we were told by the IANA that ip6.int is/was ok,

Really Bill. The world has changed quite a lot since those decisions
where made. Not all for the better.

> 	IANA and believe them on a potential political debate?

ICANN deals with TLDs these days, so the question is are we
comfortable with the assumption that ICANN will work things out in
favor of our best interests.

Thomas