Subject: Re: IPv6 will never fly: ARIN continues to kill it

From: [email-masked] (Noel Chiappa)
Date: Thu, 13 Sep 2007 01:57:29 -0400 (EDT)

> From: Jeff McAdams <[email-masked]>

    > It seems that nanog is focused (somewhat understandably) on the ideas
    > of the ISP world.
    > ...
    > The sooner ISPs quit trying to fight this fight, and just start
    > implementing this stuff widely, the better off everyone will be.

And here I am, not having gotten any money from ISP's; I'd better go look in
my mailbox for my apparently missing checks. But I digress...

    > In the enterprise world, where I live now, IPv6 is just flat out a
    > non-starter without PI space. Its just not even a discussion that's
    > even useful to have, because the answer to IPv6 without PI is just "No."

Let me see if I understand this. Without PI, the enterprises say no, and with
PI, the ISP's say no. Got it.

Just out of curiousity, how do the enterprises expect to exhange bits without
ISP's?

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Tony Li <[email-masked]>
Date: Wed, 12 Sep 2007 23:59:56 -0700

> PI, the ISP's say no. Got it.

I believe that a more constructive assessment is that enterprises are  
unwilling to pay non-trivial costs to renumber, and ISPs are  
unwilling to pay non-trivial costs to support a non-scalable routing  
subsystem.

This perspective is soluble, but it's not the perspective that we  
seem to approach the problem from.  We also don't have the solution  
in hand today, but work towards it would be greatly accelerated by  
backing away from our long-standing positions, terminologies and  
arguments and truly focusing on the problem at hand.

Regards,
Tony

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 13 Sep 2007 16:05:09 +0900 (JST)

> unwilling to pay non-trivial costs to support a non-scalable routing  

	my persistent question to the enterprise operator is this:
	how frequently do you plan to switch your isp, or how many times
	did you do that in the past?

	i have never got any reasonable answer from anyone.

itojun

---

From: Tony Li <[email-masked]>
Date: Thu, 13 Sep 2007 00:27:39 -0700

> 	did you do that in the past?

That's actually irrelevant.  Regardless of the real answer,  
enterprises are
not willing to buy into vendor lock.

Tony

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Sep 2007 18:10:04 +1000

> enterprises are not willing to buy into vendor lock.

	Except there really is no vendor lock anymore.  It is
	possible to automate the entire renumbering process.  If
	there are spots where it is not automated then they should
	be found and fixed.

	One of the best ways to get these things fixed would be for
	the router/firewall/... companies to actually switch between
	prefixes on a regular (monthly initially) basis.  This of
	course assumes that they are using their own products.

	Can my firewall be reconfigured just by adding/deleting a prefix?
	Can my router be reconfigured just by adding/deleting a prefix?
	Can my ...

	Similarly multi-home some sites out of PA space and regularly
	break connectivity on to one or more providors.  Nothing
	like doing to work out the bugs is the system.

	Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Sep 2007 12:13:20 +0300

Mark,

> 	there are spots where it is not automated then they should
You must have access to technology that at least I'm
not aware of.  We can automate some parts of the process,
like hosts can get new addresses via RA, DHCP, and we
have some tools for renumbering routers. But what about
addresses embedded in firewall configs, applications,
DNS, etc?

Jari

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 13 Sep 2007 18:27:39 +0900 (JST)

> not willing to buy into vendor lock.

	if the management needs to be convinced by the cost, i would suggest
	ISPs to price PI advertisement like hell ($$$), so that we can make
	the worldwide routing table smaller.
	it will help ISPs use smaller peering routers in the end.

itojun

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Sep 2007 10:32:59 +0100

> 	i have never got any reasonable answer from anyone.

OK, I'll bite.   Never, and never (in nearly 20 years).   Although we
in effect have IPv4 PI as being an older university we came online when 
getting an old Class B was easy, before IP allocations were made from
the NREN space.

We have renumbered our IPv6 networking as part of experimental/research
work (and would from that experience certainly say fully automated
renumbering is not possible today), but that was just an academic (and
very interesting) exercise.

If IPv6 PI were available to us we'd use it because it costs us no extra
to do so.  

-- 
Tim

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 07:19:09 -0400

> 	possible to automate the entire renumbering process.
>   
I don't believe that for a millisecond.  There are way too many places
that IP addresses creep into the configuration of components from layer
3 all the way to layer 7 (and beyond).  The idea that "people shouldn't
do that" is just religion, and not a widely-held religion.

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 12:21:48 +0100From [email-masked] Thu Sep 13 07:20:06 2007

---

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Sep 2007 07:28:44 -0400

Hear, hear.  We're making binary claims in a grey-scale world of  
economics.

Put the costs on the table and let the enterprises and ISPs fight out  
PI/PA.

- Ralph

On Sep 13, 2007, at Sep 13, 2007,5:27 AM, Jun-ichiro itojun Hagino

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 07:39:33 -0400

> Put the costs on the table and let the enterprises and ISPs fight out

The only problem I have with that is that the market tends to not be
very foresighted - it will happily lead itself into a corner from which
escape is quite difficult. 

Keith

---

From: Jeff McAdams <[email-masked]>
Date: Thu, 13 Sep 2007 07:39:52 -0400

> 	there are spots where it is not automated then they should

Oh man, that's rich.  Do you actually believe that?

I think you forgot to set your alarm clock and are living in that dream
world that I mentioned previously.
-- 
Jeff McAdams
"They that can give up essential liberty to obtain a
little temporary safety deserve neither liberty nor safety."
                                       -- Benjamin Franklin

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 13 Sep 2007 20:39:46 +0900 (JST)

> getting an old Class B was easy, before IP allocations were made from

	i would like to hear more opinion from organizations that have
	connected to the internet more recently.

	the problem i'm seeing in the ietf is (of course there are exceptions):
	- vocal people have class B/C for their own use so they are not
	  really feeling the pain of NAT (and they are contributing to the
	  bigger size of the routing table)
	- vocal people are not using IPv6 daily

itojun

---

From: Jeff McAdams <[email-masked]>
Date: Thu, 13 Sep 2007 07:46:33 -0400

> Just out of curiousity, how do the enterprises expect to exhange bits without

They will find ones that will, or they will start ones that will, or
ones will start independently that will.

And, yes, the entrenched ISP interests really should perceive that to be
a business threat, because it is one.

(I just realized that I mentioned nanog in my previous message...I'm so
used to this discussion happening over there that I just assumed that
was there this message was coming from.  Regardless, the sentiments
against PI space in IPv6 are very ISP-centric and just as ill-fated
whether they're on ietf or nanog.)

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Sep 2007 21:47:24 +1000

> addresses embedded in firewall configs, applications,

	For the DNS use UPDATE to update the address records.
	For firewall configs. See your firewall vendor.
	Very very applications need raw addresses.  Use the DNS.

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 13 Sep 2007 07:51:38 -0400

> 	i have never got any reasonable answer from anyone.

Based on the high volume, fairly small enterprises I deal with,  
roughly every 2 - 3 years.

If the Internet and its costs are truly critical to an enterprise,  
then either cost of service or quality of service perturbations mean  
that switching is fairly likely with time (or, at least, this has  
been the case in the past). The biggest barrier to switching is  
typically legal, not technical. (Switching may require breaking  
contracts & paying penalties.)

I don't claim a representative sample, but it's a data point.

Regards
Marshall

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Sep 2007 22:01:07 +1000

> >>>> I believe that a more constructive assessment is that enterprises ar> e
> >>>> unwilling to pay non-trivial costs to support a non-scalable routing> 
> >>>> subsystem.

	If you design the network for IPv6 and not just copy the
	IPv4 model.  If you use the technology that has been developed
	over the last 20 years, rather than disabling it, yes it is
	possible.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 13 Sep 2007 13:09:07 +0100

> Oh man, that's rich.  Do you actually believe that?

Welcome to the IETF, where dreams are made reality.

I particularly agree with Mark's final sentence, there - if  
renumbering is a problem, let's solve it.

FWIW, I'm pretty sure that the vast majority of renumbering activity  
*is* automated, we've simply forgotten that it's already done. We've  
got autoconf, we've got DHCP, we have oodles of technology that's  
deployed already.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: <[email-masked]>
Date: Thu, 13 Sep 2007 13:33:23 +0100

> 	over the last 20 years, rather than disabling it, yes it is

OK, how is it possible to automate the renumbering of my firewall
entries which contain IPv6 addresses and prefixes?

How is it possible to automate the renumbering of my extranet business
partner firewalls who also contain some of my IPv6 addresses and
prefixes?

How do I automate the renumbering of router ACLs in my own IPv6 network?

These are purely theoretical questions, but I do know of many instances
where these kinds of things do need renumbering when an IP address
prefix changes.

Please don't say DEN, WBEM, etc.

--Michael Dillon

---

From: Jeff McAdams <[email-masked]>
Date: Thu, 13 Sep 2007 08:34:11 -0400

> I particularly agree with Mark's final sentence, there - if renumbering
> is a problem, let's solve it.

> *is* automated, we've simply forgotten that it's already done. We've got
> autoconf, we've got DHCP, we have oodles of technology that's deployed
> already.

Yes, automated technologies handle 80% or 90% or even 99% if you've been
draconian in designing your provisioning systems.  Its that remnant that
makes the process infeasible, and that's not going to be fixed with
better protocol designs or technology implementations.
-- 
Jeff McAdams
"They that can give up essential liberty to obtain a
little temporary safety deserve neither liberty nor safety."
                                       -- Benjamin Franklin

---

From: Jeff McAdams <[email-masked]>
Date: Thu, 13 Sep 2007 08:35:49 -0400

> 	over the last 20 years, rather than disabling it, yes it is

Yep, dream-world.

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 10:14:13 -0400

> 	Very very applications need raw addresses.  Use the DNS.
Bad idea.  DNS fails a lot more often that IP addresses change.

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 10:22:21 -0400

> 	over the last 20 years, rather than disabling it, yes it is
That helps, but understanding of IPv6 and mindshare is even harder than
forklift upgrades.  And you have to educate everyone who might need to
configure an application, not just network admins.   And if you start
looking for technology that would let you automate renumbering your
entire network, you might find that the technology that exists is
incomplete and unproven.  I have yet to see a reliable, standard way to
transmit address-based access-control information to applications, for
instance.  (don't tell them to use DNS, because besides being too
unreliable to use for this, I am not aware of a DNS record that can
transmit a list of IP address prefix/netmask pairs to applications, or
of a standard API that would allow applications to find such
information.  oh yes, and practical use of DNS security still seems to
elude us.  and yeah, we shouldn't be using IP addresses for access
control - but the general purpose technology to replace that doesn't
seem to exist yet, so for the time being people are making do with what
they have.)

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 Sep 2007 00:34:14 +1000

> entries which contain IPv6 addresses and prefixes?

	Ask your firewall vendor.  It isn't rocket science to add
	support for multiple prefixes.  If you all ask they will
	listen.
 
> partner firewalls who also contain some of my IPv6 addresses and

	Configure a secure channel to push that information to them.

	I do that today for IPv4 for my home network.  My ISP changes
	my address and I automatically inform the people that need
	to know of the address change.  I also get zero advance
	notice of the address change.  I just wake up in the morning
	and find that it has changed at 3 am.  Happens about once
	every 3 months.

> How do I automate the renumbering of router ACLs in my own IPv6 network?

	Talk to your router vendor.

	I was not kidding when I suggested that router and firewall
	vendors should renumber regularly.  The only way to make
	this sort of thing work is to exercise the path until all
	the problems are gone.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 Sep 2007 00:49:07 +1000

> forklift upgrades.

	I'll agree that it is hard.  That's why the clue x 4 keeps having
	to be applied.

> And you have to educate everyone who might need to configure an application,
> not just network admins.

	The network admins are a early step.

> And if you start
> incomplete and unproven.

	Which is why I keep saying.  Run through the renumbering exercise.
	Find the problems.  Report them to your vendors.  Vendors being
	proactive would be a big help here.

> I have yet to see a reliable, standard way to
> transmit a list of IP address prefix/netmask pairs to applications,

	It exists.

> or of a standard API that would allow applications to find such
> information.

	They also exist.

> oh yes, and practical use of DNS security still seems to
> elude us.

	It will as long as people don't actually sign there zones.
	Have you asked for cs.utk.edu to be signed?

% dig dnskey cs.utk.edu

; <<>> DiG 9.3.4-P1 <<>> dnskey cs.utk.edu
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46982
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;cs.utk.edu.                    IN      DNSKEY

;; AUTHORITY SECTION:
cs.utk.edu.             900     IN      SOA     dns01.cs.utk.edu. miturria.cs.utk.edu. 2007090900 10800 1800 604800 900

;; Query time: 387 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 14 00:46:21 2007
;; MSG SIZE  rcvd: 79

% 

>  and yeah, we shouldn't be using IP addresses for access

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 10:58:56 -0400

> 	I'll agree that it is hard.  That's why the clue x 4 keeps having
That's a LOT of people to whack on the side of the head.  And it pretty
much has to be done in meatspace; the net doesn't help you out with this
problem.
> 	proactive would be a big help here.
Yes they would.  But basically everyone can assume that this is Somebody
Else's Problem.  You want to make it the problem for the network admins,
sysadmins, users, application writers, and firewall vendors to solve. 
Those people  want to make it the problem for the carrier ISPs and
router vendors to solve.

And really, fixing the routing system so that it can provide stable
global PI addresses to everyone (say, via something LISP-like) might be
easier...especially that the need to renumber isn't the only problem
that lack of stable global PI addresses causes.

> 	Have you asked for cs.utk.edu to be signed?
I don't work there any more, so it's Somebody Else's Problem.  :)

And really, there's no way I'd trust DNS to do this.  I've spent too
many years watching it break.

Keith

---

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 13 Sep 2007 08:22:36 -0700

This is a constructive and helpful posting, Tony. Thank you.

Am I correct in presuming that both Noel and you believe that the
possible technical solutions to this problem are currently being
considered in the RRG / RAM discussions?

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
On Sep 12, 2007, at 10:57 PM, Noel Chiappa wrote:
> Let me see if I understand this. Without PI, the enterprises say no, 
> and with PI, the ISP's say no. Got it.

I believe that a more constructive assessment is that enterprises are
unwilling to pay non-trivial costs to renumber, and ISPs are unwilling
to pay non-trivial costs to support a non-scalable routing subsystem.

This perspective is soluble, but it's not the perspective that we seem
to approach the problem from.  We also don't have the solution in hand
today, but work towards it would be greatly accelerated by backing away
from our long-standing positions, terminologies and arguments and truly
focusing on the problem at hand.

Regards,
Tony

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 Sep 2007 01:28:07 +1000

> Those people  want to make it the problem for the carrier ISPs and

	I've spent a lot of time adding support to make renumbering
	easier in the places that I can change.  I will continue
	to do that.

	I can't however fix every problem.

> many years watching it break.

	It breaks much less often once you allow it to be automated.
	We could in theory have all nameservers update the parent
	servers with appropriate glue.  This is not technically hard
	to do.  Similarly NS RRsets.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Sep 2007 15:41:41 +0000

> many years watching it break. --Keith

i suspect that you're measuring the wrong thing, or that you're not paying
attention to the "what" that you're measuring.  in a every distributed system
of sufficient size, there is always something broken somewhere.  the sysadmins
at ISC were for example concerned when the trend of broken f-root hosts got to
the 1-a-day level until someone pointed out that once you've got more than 100
systems at least one will always have something wrong with it and it's a good
thing we put two in every POP and have a lot of POPs isn't it?

yes, DNS is always broken.  so is the routing table.  so is the airline system
and most road systems and the stock market.  and it always will be broken,
since in systems of sufficient size, entropy and human error are signigicant
enough to be noticed.  if you don't want to use something that will break, you
ought to start by pulling the power cord out of all your servers and routers.

it's just not reasonable to demand 100% uptime from a million-node distributed
system where most of the nodes are operated by other people.  doesn't matter
if the nodes are BGP routers, web servers, DNS servers, or botted home PC's.

odell's 8+8 relied on DNS for location->routing mapping and that could be one
of the reasons it had so little support.  but in the decade+ since then, DNS
has scaled better than the routing system.  odell had a reasonable design but
it lacked the architectural purity of... whatever it is we're using instead.

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 12:05:04 -0400

Okay, let me say this more precisely.  I've seen too many occasions over
the years where DNS was broken so badly that the only way to get things
fixed, or to get work done, or to keep applications operating, was to
bypass DNS - either by typing in an IP address somewhere.   And of
course those alternative mechanisms also break - but the combination of
mechanisms work better than DNS alone.  And of course one of the reasons
that the combination works better is that the addresses of "important"
hosts rarely change.

I'm not saying that DNS can't be improved to be more reliable - clearly
it can.  I'm not saying that DNS hasn't been improved - clearly it has,
though old habits die hard and users are slow to change what "works" for
them.  But putting _all_ addresses in DNS makes DNS failures a lot more
critical than they are now, and there are good reasons for being
reluctant to do that.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Sep 2007 16:08:53 +0000

> > > 	my persistent question to the enterprise operator is this: how
> > > 	frequently do you plan to switch your isp, or how many times did you
> > > 	do that in the past?
> > 
> > That's actually irrelevant.  Regardless of the real answer, enterprises
> > are not willing to buy into vendor lock.
> 
> 	the worldwide routing table smaller.  it will help ISPs use smaller
> 	peering routers in the end.

that's not how business economies work.  many isp's are hoping that other
isp's adopt the pricing model you propose above, because it will drive sales
toward the isp's who don't adopt it.

the middle quote above is perfectly correct: "that's actually irrelevant."
as the "cost of renumbering" slider moves upward, so will the "price gouging
by ISP's".  nobody wants to leave money on the table.  a business who knows
it will be difficult to renumber also knows that whatever ISP they choose
will use that difficulty as leverage whereby their service level will be low
and their pricing will go higher.  PI is counter-leverage.  without it, you
get NAT, with small islands of PA on the outside and probably IPv4 on the
inside.

telling ISP's what they should do when it will mean making less money is a
waste of your time and theirs.  telling enterprises what they should do when
it means paying more money is likewise a waste of everybody's time.  this is
not a managed economy.

imagine cisco using verizon-provided PA space to number every workstation and
wireless LAN and router and server in the company.  would they be so foolish?
(i'm not picking on verizon here, as far as i know they run a fine network.)

now imagine ford motor company.  or toyota.  or wal-mart.  or any bank.

is it only the large companies who can't afford the risk of price lock-in?
so, imagine home depot or norwegian cruise lines.

if i were the CIO of any of those companies, i'd say "PI or NAT, exclusively"
and if i didn't, then i'd expect the board and shareholders to hunt me down
and kill me once the bills started coming due.

(i'm signing off for the day, having reached what i think is a reasonable
quota for one mailing list in one day-night cycle, and i've delete-paragraphed
a whole rant tying this back to the Tyranny of the Core and ula-global.)

---

From: Tony Li <[email-masked]>
Date: Thu, 13 Sep 2007 10:11:34 -0700

> How do I automate the renumbering of router ACLs in my own IPv6  

As a practical matter, these things are quite doable.  Sane network  
management
practices store the configuration for such devices in offline  
management stations.

By then writing these configurations in a parameterized form, you can  
then use
the current variable definitions to expand out a concrete  
configuration.  The tools
for this are not rare.  Languages such as Perl, or macro processors  
such as cpp or
m4 are more than adequate to the task.

Loading the results of these tools into devices is also trivial.  See  
rancid, for example.

For larger cases, one can also integrate a SQL database to help  
provide organized
scalability.

This is not theoretical, I've worked with all of the above.

Regards,
Tony

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Sep 2007 10:17:58 -0700

> renumbering is a problem, let's solve it.

How do you renumber the IP address stored in the struct sockaddr_in  
in a long running critical application?

Regards,
-drc

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 13 Sep 2007 12:26:11 -0500

From: "Dave Cridland" <[email-masked]>

> FWIW, I'm pretty sure that the vast majority of renumbering activity  *is* 
> automated, we've simply forgotten that it's already done. We've  got 

My apologies for intruding, because I haven't been following the technology 
during the past couple of years, but V6OPS did an informational RFC on 
renumbering without a flag day (http://www.ietf.org/rfc/rfc4192.txt) in 
2005.

I thought the document was helpful when I last looked at it 
(prepublication).

There may be additional types of devices that have become more widely 
deployed during the past couple of years, that would be affected by 
renumbering - I'm thinking about SBCs, or Session Border Controllers, as one 
example - but I think the document addresses these devices in a generic 
way - the extreme form of caching addresses is sticking them in 
configuration files, but this is a difference of degree, not of kind, from 
the caching discussion in the document.

I'm copying the v6ops chairs, so perhaps they can clarify something...

This RFC identified a couple of opportunities:

4.  Call to Action for the IETF

   The more automated one can make the renumbering process, the better
   for everyone.  Sadly, there are several mechanisms that either have
   not been automated or have not been automated consistently across
   platforms.

4.1.  Dynamic Updates to DNS Across Administrative Domains

4.2.  Management of the Reverse Zone

Have these holes been filled in during the past couple of years?

Thanks,

Spencer

---

From: Tony Finch <[email-masked]>
Date: Thu, 13 Sep 2007 19:36:47 +0100

> 	For the DNS use UPDATE to update the address records.

Since when did that work for delegation changes?

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

---

From: Tony Finch <[email-masked]>
Date: Thu, 13 Sep 2007 19:43:38 +0100

On Thu, 13 Sep 2007, David Conrad wrote:
>
> How do you renumber the IP address stored in the struct sockaddr_in in a
> long running critical application?

Applications that don't respect DNS TTLs are broken for many reasons, not
just network renumbering.

Tony.

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 14:52:56 -0400

> just network renumbering.
Since neither TCP nor UDP respect DNS TTLs it seems a bit of a stretch
to expect apps to do so.

And for that matter, a DNS name is not a host name, and hasn't reliably
been a host name since at least the mid 1980s.   Just because you get
address A1 from doing a lookup on a name at time T1 and an address A1
from doing the same lookup at time T2, doesn't mean that those addresses
will connect to the same (layer 3 or higher) stack. 

So even if we somehow magically changed our existing transport protocols
to be able to support changes to endpoint addresses on the fly, DNS
names as they are currently used are not suitable as endpoint
identifiers for such a purpose.  At best, existing DNS names serve as
identifiers for the initial contact only.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 14:59:50 -0400

> will connect to the same (layer 3 or higher) stack. 
sorry, typo.  I meant to say "...an address A2 from doing the same
lookup at time T2, ..."

Keith

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Sep 2007 12:31:14 -0700

> just network renumbering.

Then pretty much every IP-aware application ever written is broken.

If you had a separation between locator and identifier, the  
application could bind to the identifier and renumbering events could  
occur on the locators without impacting the identifier.  Long running  
critical applications wouldn't even notice.  You could even get stuff  
like simple multi-homing and transparent mobility for free.  People  
would live in peace and harmony for ever and ever. Etc.

But we don't have that separation.

We are burdened with an architecture that was designed before we had  
how this whole "Internet" thing was going to work beaten into the  
operational community's heads with large sticks.

We had an opportunity to fix that, but we blew it.  We kept the same  
architecture, just making it bigger and ignoring the operational  
problems that architecture imposed (and some people at the time  
argued this was a good thing).  But hey, at least we weren't saddled  
with that evil OSI TP4/CLNP stuff.  We showed them, didn't we?

We appear to now be at a point where more folks have realized that we  
have to either come up with IPngng or backfit some kludge onto IPng  
to address the operational problems that existed in IP and were  
carried over into IPng because it is just IP with more bits.

Unfortunately, we're now looking down the barrel of exhaustion of the  
IPv4 free pool (2 to 3 years, based on current projections), so we  
don't even have the luxury of time to bicker about it anymore.   
Doesn't mean we won't bicker, of course.

I suspect we have 3 alternatives:
a) IPv4+NAT
b) IPv6 with aggressive prefix length filters and highly  
indeterminate reachability for longer prefix PI address holders.
c) IPngng (maybe IPv6 with some sort of locator/id split hacked onto it)

The default will be (a).

"Choose wisely."

Regards,
-drc

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Sep 2007 23:05:22 +0300

David,

> We had an opportunity to fix that, but we blew it.

I think everyone agrees that having that flexibility
(ease of renumbering, no routing explosion in the
core etc) would be good.

But I would suggest that instead of playing the
"what if" or "I told you so" games, we collectively
focus on solving the problem. And getting it solved
means having a solution that actually works, has all
the little details (like what the security is etc) worked
out, fits with the incentives that the various players
have, and so on.

And we have a place for that work to happen in the
IRTF. There's a lot of promising work, but they
don't have a final solution yet; the details do matter
(and I suspect that they also mattered back at the
time IPv6 was being designed).

Jari

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 16:16:20 -0400

> b) IPv6 with aggressive prefix length filters and highly indeterminate
> reachability for longer prefix PI address holders.
it's not at all clear that these are mutually exclusive.

IPv4+NAT is here and it's not going away anytime soon.  Even if an ideal
solution using IPv6 were to surface tomorrow,  we'd still be dealing
with IPv4+NAT for 10 years or so.   The most popular applications that
exist today will be the last ones to move to IPv6 (or to stop supporting
IPv4) because those are the ones that have the most investment in IPv4
and NAT workarounds.  To put it another way, IPv4 is part of the
critical infrastructure for those applications.  They might start
supporting IPv6 in addition to IPv4, but IPv4 support will be the
necessary condition for interoperability of those applications until
IPv6 is as ubiquitous as IPv4.  Meanwhile there will be a need to host
applications on IPv6-only networks that still have access to the global
IPv4 infrastructure - and the solution to this probably ends up looking
a bit like a NAT (though one in which apps are explicitly aware of and
control the bindings rather than something like NAT-PT that tries to
fool apps into thinking it isn't there).

IPv6 with PI addresses seems likely - the only question is how big you
have to be to get a PI address prefix.  In the near term, scalability is
not an issue, but if IPv6 is at all successful the growth in routing
table sizes, updates, etc. could be quite steep.  Prefix length filters
might not be the mechanism used to decide which prefixes get routed and
which ones don't, but there will be some mechanism for this.

Lots of versions of LOC+ID split have been talked about over the years. 
A lot of people believe in the concept, but the devil is in the
details.   Still, my impression is that newer proposals in this area are
more realistic than those I saw a few years ago, both in actually being
implementable and in accommodating the diverse set of interests that is
the Internet.  I think it will still take a few years for a
standards-quality solution to emerge.  Meanwhile, we'll be using some
mixture of the above.  We might or might not get a good LOC+ID solution
in place before the routing scalability limitations of PI addresses
result in another crisis.

But I really don't think we have the luxury of choosing one of these
over the other.  We need to work on all of these, and more.   We need to
think of them as complementary approaches rather than competing ones,
even while we recognize that some of them have much better long-term
viability than others.

Keith

---

From: Karl Auerbach <[email-masked]>
Date: Thu, 13 Sep 2007 14:00:49 -0700

...
> If you had a separation between locator and identifier, the application 
> could bind to the identifier and renumbering events could occur on the 
> locators without impacting the identifier.

For a long time I've suggested that we begin to look anew at the idea of 
an "association" as an abstraction over "transport".  Yes, I know that 
this smacks if ISO/OSI, but there were a few granules of good ideas there.

The idea is this:  An "association" is an end-to-end relationship 
between a pair of applications that potentially spans several transport 
lifetimes.

Then, if the underlying transport goes away, perhaps due to movement in 
a mobile network or renumbering, then the association is reconstructed 
on a new transport that is built in accord with the current addressing 
and routing conditions.

Reconstruction does not, as some have assumed, require that the network 
remember anything or hold any state.  Rather, taking a cue from ISO/OSI, 
the trick is that the association layer is merely a means for the 
applications to reliably exchange checkpoint names.  What those 
checkpoint names mean is up to the applications - thus what to do if a 
rebinding to a new transport requires going back to a checkpoint is 
something entirely within the application and its networking library 
code, not some state that is stored in the net.

Basically whenever applications establish a transport they say "Ahem, 
where were we when we last spoke".  One answer is "We did not last 
speak"  Another answer is "we last agreed on the checkpoint named 
'foo'".  How they recover from 'foo' is entirely application dependent.

(I have not really considered the security implications - in the absence 
of some form of shared secret or other authentication on association 
re-establishment there would probably be a race condition in which an 
intruder could jump in.)

(I'm also thinking of TCP based applications, not UDP based ones.  For 
them I don't see renumbering as much of a problem, but I may not be 
seeing enough.)

This is not something that can readily be transparently back-ported into 
existing protocols; it's not something of trivial import.  But it can be 
deployed for new applications and not invalidate either existing 
applications or existing application protocols.

And consider, for example, how something like this might have obviated 
the need for the IP layer triangulation in mobile IP.

		--karl--

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 17:18:22 -0400

Offhand I don't know why it should be necessary to build a mechanism
that spans several transport lifetimes.  I would much prefer that we
re-engineer our transport protocols to let them work in terms of
endpoint IDs.  In particular, checkpoints would seem to make life more
complicated for applications by lowering the level of service from
transport protocols - because I think it would be hard to implement
transport-independent and application-independent checkpointing in a way
that made sense.

I do however think that there might be a place for a mini layer in
between IP and transport that accomplished a few things that we seem to
need in all transports.  e.g. management of ID-LOC mapping, management
of multiple LOCs per endpoint ID, striping of traffic across multiple
paths, management of RTT and other estimators, congestion control, peer
authentication, encryption, and explicit interaction with layer 3
intermediaries. 

Keith
> For a long time I've suggested that we begin to look anew at the idea
> of an "association" as an abstraction over "transport".  Yes, I know
> that this smacks if ISO/OSI, but there were a few granules of good
> ideas there.
>
> between a pair of applications that potentially spans several
> transport lifetimes.
>
> Then, if the underlying transport goes away, perhaps due to movement
> in a mobile network or renumbering, then the association is
> reconstructed on a new transport that is built in accord with the
> current addressing and routing conditions.
>
> Reconstruction does not, as some have assumed, require that the
> network remember anything or hold any state.  Rather, taking a cue
> from ISO/OSI, the trick is that the association layer is merely a
> means for the applications to reliably exchange checkpoint names. 
> What those checkpoint names mean is up to the applications - thus what
> to do if a rebinding to a new transport requires going back to a
> checkpoint is something entirely within the application and its
> networking library code, not some state that is stored in the net.
>
> (I have not really considered the security implications - in the
> absence of some form of shared secret or other authentication on
> association re-establishment there would probably be a race condition
> in which an intruder could jump in.)
>
> This is not something that can readily be transparently back-ported
> into existing protocols; it's not something of trivial import.  But it
> can be deployed for new applications and not invalidate either
> existing applications or existing application protocols.
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Sep 2007 23:24:02 +0200

>>> long running critical application?

Disconnect current session, reconnect.

>> just network renumbering.

Since when is it the job of applications to manage DNS TTLs?

> Since neither TCP nor UDP respect DNS TTLs it seems a bit of a stretch

Right.

> identifiers for the initial contact only.

This falls under the heading of "nobody is stopping us from doing  
this and it works today so now it's a feature and it can never be  
taken away". Giving in to this logic means that it's impossible to  
change ANYTHING. As the saying goes, in an infinite universe,  
everything that's possible, does indeed exist. The internet is pretty  
much an infinite universe these days.

As for renumbering, on a Cisco router, I can make the following  
configuration:

!
interface Ethernet1
  ipv6 address autoconfig
  ipv6 dhcp client pd dhcpv6prefix
!
interface Ethernet2
  ipv6 address dhcpv6prefix 0:0:0:A0::/64 eui-64
!

This way, the router obtains an IPv6 prefix dynamically from a DHCPv6  
prefix delegation server and then sends out router advertisements  
using that prefix. So you can renumber the router and all the hosts  
connected through it by changing one entry in a DHCPv6 server config.  
However, I don't think this method applies everywhere (such as in  
filters) but obviously that's something that would be possible if  
desired.

Even with the current state of the art I'd say that renumbering  
clients is not a big deal. Renumbering servers is more difficult,  
though.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Sep 2007 23:34:49 +0200

> between a pair of applications that potentially spans several  

Wouldn't that be the OSI session layer (that IP doesn't have)?

> taking a cue from ISO/OSI, the trick is that the association layer  
> is merely a means for the applications to reliably exchange  
> checkpoint names.  What those checkpoint names mean is up to the  
> applications - thus what to do if a rebinding to a new transport  
> requires going back to a checkpoint is something entirely within  
> the application and its networking library code, not some state  
> that is stored in the net.

We already do that today at the TCP layer. Rather than reinvent TCP  
in all individual applications (all those checkpoints will be great  
for performance!) it's much easier to hide changes in IP connectivity  
from TCP. We also pretty much have that today, in the form of shim6.

Note thought that none of that solves renumbering, rather, it really  
needs better renumbering support to work well.

> association re-establishment there would probably be a race  
> condition in which an intruder could jump in.)

Seperating location and identity requires some pretty hefty security,  
otherwise anyone can impersonate anyone.

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 17:42:51 -0400

> Disconnect current session, reconnect.
Uh, not unless your application has some sort of retry or
checkpoint-restart capability.   SMTP is pretty resilient in the face of
connection breakage, and for some interactive applications you just hit
"retry" or the equivalent, which has caused some people to think that
somehow it's okay if the network changes a host's IP addresses out from
under it.  But it doesn't work in general.
> This falls under the heading of "nobody is stopping us from doing this
> and it works today so now it's a feature and it can never be taken away". 
No, it just means that people shouldn't assume that existing DNS names
(i.e. the ones we're already using to identify hosts and services) will
work as endpoint identifiers for the purpose of connection restart.  
People are using DNS names to name things that aren't hosts (e.g.
services or groups of hosts) for valid reasons and any solution that
destroyed this functionality would be a non-starter.

> [deleted for brevity]
That's the least of the problems with renumbering.  A few years ago I
was involved in renumbering of a class B IPv4 network.  DHCP and DNS
doesn't even begin to cover it.
> clients is not a big deal. Renumbering servers is more difficult, though.
The distinction between client and server is fairly meaningless.  It's
certainly not something you want to assume in a renumbering
architecture.  Every host is a server in some sense.

Keith

---

From: Tony Li <[email-masked]>
Date: Thu, 13 Sep 2007 14:51:29 -0700

> Wouldn't that be the OSI session layer (that IP doesn't have)?

Not necessarily.  A 'session' in the OSI verbiage (at least as far as  
I can understand it ;-), spans across individual transport  
connections.  The de-facto session layer that we have today in IP is  
an ssh tunnel, with applications tunneled across it and some very  
poor security within that tunnel.

A key question here is whether the 'association' is a single  
connection or not.  While the association may span the change of  
underlying infrastructure, the real question is whether it presents a  
single concatenated transport abstraction or if it's multiple  
connections.  I think we need the former.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Sep 2007 00:01:16 +0200

> under it.  But it doesn't work in general.

I think the way IPv6 handles this by deprecating the current address  
but keeping it alive for some time is entirely reasonable. So if  
you're doing a large file transfer or something like that, you can  
finish it, then disconnect and reconnect using the new address.

Assuming that you can keep a session alive for weeks or months  
without the ability to recover from disconnects is not a smart idea,  
to say the least.

>> this

> work as endpoint identifiers for the purpose of connection restart.

Huh?

What ARE DNS names good for, if not that?

Obviously if people put a bunch of hosts in the DNS under a common  
service name, the idea is that all of the hosts provide the service  
in question.

I also don't feel responsible for keeping the host/service  
distinction. If a certain protocol needs to talk to individual hosts  
and not services, then the people creating DNS names for use with  
that protocol should take that into account and not whine.

> destroyed this functionality would be a non-starter.

Like I said, EVERYTHING is a non-starter today so we don't start  
anything anymore. The assumption that everything that works today  
will continue to work forever is broken.

> doesn't even begin to cover it.

You have to design to be renumberable.

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Sep 2007 15:22:23 -0700

Jari,

> (ease of renumbering, no routing explosion in the

So would world peace, motherhood, and apple pie.  What are you  
willing to give up for it?

> focus on solving the problem.

And I would suggest by ignoring history we are doomed to repeat it.   
I am not engaging in "I told you so" because I didn't -- you'll note  
I used "we".  I am merely pointing out that we're either at or very  
quickly approaching a crossroads and the choices we have are  
constrained by the reality of the Internet today and past decisions  
we, the IETF, have made.

IPv6 _is_ IPv4 with more bits and it is being deployed that way.  One  
can argue that it shouldn't be that way and that there should be a  
paradigm shift in the enterprises, ISPs, and grandmothers of the  
world, but commercial reality makes such a shift very, very hard.

> And getting it solved

Do you believe IPv4 (or ANY other successful large scale technology),  
when it was designed, had all the little details worked out?

As I have said elsewhere, I've come to believe that one of the  
fundamental failures of the IETF is that it permits or even  
encourages protocol design to be directed by corner cases.  In this  
particular case, it isn't even clear to me there is agreement on what  
the problem we're trying to solve actually is.

> And we have a place for that work to happen in the IRTF.

Actually, I suspect if the work were to happen in the IRTF, it would  
be doomed.  The IRTF is, after all, focused on research.  I can  
imagine the people in the IRTF contributing towards a solution but  
that isn't where a solution will come from.  Given real world  
constraints, a solution will come from engineers (protocol, network,  
hardware, and/or software), singly or working together, coming up  
with an approach that meets real world requirements (not what  
researchers believe are real world requirements).  It almost  
certainly won't be architecturally pure and it probably won't be  
pretty, but it will probably meet commercial and operational needs.

Regards,
-drc

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Sep 2007 02:24:53 +0400

> Have these holes been filled in during the past couple of years?

No.

While some might point to existing renumbering RFCs, speaking from  
the perspective of my employer, Cisco doesn't think it makes  
operational sense. What it handles is the special case in which an  
administration
  - wants to change its /48 ISP prefix for another /48 ISP prefix,
  - both are exactly 48 bits long (no /56 prefixes or any other  
length allowed), and
  - in which there is no intent to change the subnet part of the prefix.

In our opinion, changing between a /48 and a /56 (or a /56 and a /52,  
or any other combination) is a pretty reasonable thing to want to do.  
Further, whenever Cisco renumbers its IPv4 network (which it does  
with some regularity it seems), we change the allocation of subnet  
prefixes. we recover what we can, re-organize, and re-deploy.

So we think the current solution is operationally useless. To my  
knowledge, we haven't heard from our customers that they want it. As  
such, we have no current plan to implement it.

---

From: Karl Auerbach <[email-masked]>
Date: Thu, 13 Sep 2007 15:34:42 -0700

Tony Li wrote:

> A key question here is whether the 'association' is a single connection 
> or not.  While the association may span the change of underlying 
> infrastructure, the real question is whether it presents a single 
> concatenated transport abstraction or if it's multiple connections.  I 
> think we need the former.

Wow, I wasn't expecting so much feedback in so few minutes.

My motivations were these:

Although I'd as a writer of applications like to have a reliable, 
sequenced data stream to my peer application(s), I figured that to do 
that inside TCP would be to reinvent TCP.  And since I don't believe 
many of us think TCP is broken, reinventing TCP would not be a good use 
of our efforts.

So I figured, OK, how can we keep our investment in TCP and existing 
applications and provide a tool that could be of use to people figuring 
out new applications.  Sort of the way that BEEP is.

And having long ago stuck more than an arm into ISO/OSI, and after 
seeing Marshall Rose's implementations of ISO session over TCP, I 
realized that what the OSI people were trying to do at the "session 
layer" was something simple wrapped up in an amazing amount of 
complexity.  All they were trying to do was give applications a way of 
putting stakes into the ground so that they could go back to an agreed 
upon status if something went wrong and give it another try.

To my mind it would be very wrong to require that the network in some 
way preserve application data for re-presentation; first off that makes 
the network too complicated and second, as several have pointed out, how 
each application recovers varies from application to application.

Keith is very right that we don't want the network (including most of 
the stack code in clients and servers) to do what an application should 
do for itself, particularly with regard to buffering of data.  That's 
why, to my mind, the "association" mechanism should be limited to merely 
letting the applications agree on a name or number, nothing more, and 
leaving it to the applications to figure out what to do if they need to 
go back to that name/number.  And Keith is right in that what I am 
suggesting would not be a mechanism that would be transparent to 
existing applications.

I've wrestled with the idea of pushing all of this down into the 
transport layer and, yes it could be done.  But I have doubts that given 
the size of the net that it would be broadly adopted or be deployable. 
So I mentally punted and said "How about an optional layer above TCP 
that newly designed applications could use?"

As Iljitsch points out, the checkpoint mechanism could become a lot of 
overhead for not a lot of benefit - although I sense that the overhead 
of establishing a checkpoint would involve perhaps one-to-two packet 
exchange/round trip times and might be able to occur in parallel with 
ongoing data flow (remember I'm suggesting only the establishment of a 
name, not any buffering of data except in the applications themselves.) 
  And a well designed application protocol should only use a the 
checkpoint mechanism when it really needs to.  It would be silly, for 
example, to checkpoint a DNS-over-TCP connection, but it might make 
sense for some mobile database access application to do it after each 
database update.

But, as Iljitsch also suggests, we can get a lot of this if applications 
simply close the TCP connection then re-open it.  But isn't that really 
a somewhat similar to I've suggested in that it requires the 
applications to go back to some point in the past and resume?

I know that I'm walking close to the edge of a cauldron of worms, but 
I've seen these ideas of some sort of persistent relationship between 
application layer entities pop up in many contexts, such as mobile IP, 
VoIP, HTTP cookies, etc, that it occurred to me that maybe it is 
something that needs some coherent, rather than ad hoc, consideration.

		--karl--

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 18:51:54 -0400

> finish it, then disconnect and reconnect using the new address.
Yeah, right.  And then every application protocol has to implement its
own checkpoint/restart capability on top of TCP. 

Actually if there were some specification for how long the minimum
overlap period should be, and it were long enough (a day, perhaps, but
not an hour), then the only applications that would need such capability
would be those which expected to have very long session times.  and that
might be acceptable.  but it's easy to think of apps that need to be
able to maintain associations for days: file transfer, remote terminal,
file access, event logging all come to mind immediately.
> Assuming that you can keep a session alive for weeks or months without
> the ability to recover from disconnects is not a smart idea, to say
> the least.
Assuming that you can change addresses out from under applications
without breaking them is even less smart.
> What ARE DNS names good for, if not that?
Initial binding of a name to an address where _an instance of_ the host
or service or application peer associated with that name can be
reached.   Once there is a relationship between the parties to a
connection, the DNS name can no longer be relied on to reach the other
party.
> service name, the idea is that all of the hosts provide the service in
> question.
It might be "obvious" but it's an oversimplification at best.
> and not services, then the people creating DNS names for use with that
> protocol should take that into account and not whine.
Yes, and somehow all of the applications and users that need to know
about the specific purpose of each of those DNS names will magically
find out.
> anything anymore. The assumption that everything that works today will
> continue to work forever is broken.
You are taking a very narrow case that I cited and exaggerating it way
out of proportion.
> You have to design to be renumberable. 
It might be a good idea, but having standards protocols, APIs, and tools
to do that are a lot further behind the curve than, say, IPv6.  If we
started in earnest now to develop those protocols, APIs, and tools, we
might have such things in place 10 years from now.  That doesn't mean we
shouldn't do it, but it does mean that statements of the form "you have
to design to be renumerable" are essentially saying that you have to be
able to adapt every host stack, router, firewall, ALG, traffic filter,
traffic monitor, and application in your network to accommodate your
particular mechanism for doing that.

Keith

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Sep 2007 16:14:34 -0700

Iljitsch,

On Sep 13, 2007, at 3:01 PM, Iljitsch van Beijnum wrote:
>> checkpoint-restart capability.
> I think the way IPv6 handles this by deprecating the current  
> address but keeping it alive for some time is entirely reasonable.

There is no real difference between how IPv4 handles this and how  
IPv6 handles it.

Applications, regardless of whether they are IPv4 or IPv6, know the  
address of the remote side of the conversation, it is cached in  
application data space.  If the address changes, the application  
needs to be made aware of that somehow.  This is usually done by a  
connection reset, often causing the program to terminate.  Unless  
you're going to rewrite pretty much every Internet aware  application  
on the planet, IP addresses (both IPv4 and IPv6) are assumed to be  
stable.

> without the ability to recover from disconnects is not a smart  
> idea, to say the least.

Is it smart?  Nope.  However, most applications were designed with  
this assumption and it works today if you have PI.

> will continue to work forever is broken.

Yep.  Question is, what's critical vs. important vs. nice-to-have?   
(I consider long term connections to be a nice-to-have, btw)

Regards,
-drc

---

From: Bill Manning <[email-masked]>
Date: Thu, 13 Sep 2007 16:23:00 -0700

> time IPv6 was being designed).

	the old PIER wg had some useful ideas on the
	scope fo the renumbering problem... if the 
	IRTF wants to revisit the problem that might
	be a good place to start.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 Sep 2007 09:52:23 +1000

> Since when did that work for delegation changes?

	The protocol has supported it from day 1.  We've shipped
	clients that supported it since 2000 (all version of BIND
	9 support it).  This was one of the architectual issues
	that was addressed in BIND 9.  We went to seperate databases
	for each zone rather than a single database.

	You can use UPDATE to update *any* record in a zone that
	includes records that are occulted by the a delegating NS
	RRset.

	The only things you can't do with UPDATE (yet) are:
	* provision a server to server a new zone.
	* decomission a zone.

	If we could get the TLD's to accept UPDATE packets I'd
	write the code to do this whenever the master server
	was updated (NS/glue changed) / restarted.  This would
	be a alternative method to going through EPP.

		zone "example.com" {
			type master;
			file "master/example.com.db";
			update-parent yes;
			update-parent-key keyname;
		};

	Mark

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 13 Sep 2007 17:29:39 -0700

David Conrad wrote:
> ....
> IPv6 _is_ IPv4 with more bits and it is being deployed that way.  

No it is not, and you need to stop claiming that because it confuses people
into limiting their thinking to the legacy IPv4 deployment model. 

> One

Transition requires that the technology meet people where they are, which is
why you note that IPv6 is being deployed like IPv4. Then once they get over
the basic education hump they can think about the different capabilities to
move beyond the historical limitations. There are way too many arguments
(even on this list of relatively smart people) where the fundamental
difference of simultaneous use of multiple addresses is the key to thinking
differently between the versions. Until people get their heads out of the
IPv4 darkness they will keep insisting on making IPv6 deployments look the
same.

> when it was designed, had all the little details worked out?

If anyone doubts this point, note that the IETF still creates more IPv4
specific RFCs than IPv6 ones. Until the IESG/IAB get serious about stopping
all work on the dead-end IPv4 protocol, people will continue to argue that
IPv6 is not ready for deployment.

> the problem we're trying to solve actually is.

There are operational practices that originate from
lack-of-memory/lack-of-reliable-resolution that end up embedding IP
addresses in places that make it very costly to change them later. The work
was done on the endpoint side to simplify renumbering, because touching the
larger number of them was clearly a problem, but it was not done in the
firewall/management system area.

> pretty, but it will probably meet commercial and operational needs.

If there is research to do towards this, it will be in the arena of social
engineering. Once it is clear how to stop operators from deciding the most
expedient thing to do is embed the current IP address into some
configuration, then engineering can build the tool to enforce that. It is
very difficult to get people to realize that the accumulation of short term
cost savings will turn on them as a sizable cost when changes become
necessary.

Tony

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Sep 2007 17:43:05 -0700

> IPv6 _is_ IPv4 with more bits and it is being deployed that way.  

Probably not really.

That sort of equivalence statement applies when the new version is a minor 
upgrade to the previous, rather than require massive changes to the 
infrastructure AND to client applications. Having to run parallel stacks, 
having substantial changes to administration and operations, and having major 
changes to the minimum required set of capabilities is more than just a few 
more bits.

Deering's SIP qualified as such a minor upgrade (if an upward compatible 
addressing scheme had been chosen.)  The current IPv6 suite probably does not.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Sep 2007 05:01:08 +0400

On Sep 14, 2007, at 2:22 AM, David Conrad wrote:

> And I would suggest by ignoring history we are doomed to repeat  
> it.  I am not engaging in "I told you so" because I didn't --  
> you'll note I used "we".  I am merely pointing out that we're  
> either at or very quickly approaching a crossroads and the choices  
> we have are constrained by the reality of the Internet today and  
> past decisions we, the IETF, have made.

Well, yes. But I do find myself wondering what tool one might really  
want to use here and how it differs from what we do in IPv4.

Correct me if I am wrong (but not here - let's have that discussion  
on v6ops). To my way of thinking, the process described in RFC 4192  
can't really be automated start to finish, and it is nonetheless  
pretty much the right process. Parts of it can be, such as once an  
operator decides he wants to add a new prefix to every router  
interface in his network, the database he uses to manage such things  
can ssh to each router and add the prefixes, and similarly when he  
decides to later remove the old, the database can do that. But the  
big problem in renumbering isn't "getting the addresses assigned". It  
is "finding and fixing all the places where that address was used in  
numeric form to ensure that they now have the right new value". Since  
human screwup behavior isn't automated, fixing human screwups is  
difficult to automate.

So we can have tools that help with the major steps, but a lot of the  
verification process can only be done by observation.

Recriminations and rants aren't going to make that much different.

What would be Really Nice would be to in some way ensure that  
applications never saw IP addresses at all - they *only* worked on  
names, and maintained no knowledge in the application of what address  
was used. To my small mind, forcing a new DNS lookup in the event of  
a TCP session failure and restart would be a good thing. The authors  
of RFC 4778 would take exception - they want to be able to log into  
the right place when everything is in flames. Apart from that,  
though, managing addresses through names would go a *long* way toward  
making renumbering easier. We already have many of those  
capabilities, though. We have to as an industry consistently use them  
that way.

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 21:47:34 -0400

Tony Hain wrote:
> Until people get their heads out of the IPv4 darkness they will keep insisting on making IPv6 deployments look the same.
>   
Perhaps, but there's such a thing as IPv6 darkness also.  For instance,
the assumption that existing applications can survive changes in the IP
addresses of the hosts on which they reside without significant changes
to those applications.  Or the assumption that it's reasonable for
applications to have to deal with multiple source and destination IP
addresses without access to routing or topology information.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 22:03:18 -0400

Fred Baker wrote:
> was used. To my small mind, forcing a new DNS lookup in the event of a
> TCP session failure and restart would be a good thing.
perhaps, but it won't work reliably as long as there can be more than
one host associated with a DNS name, nor will it work as long as DNS
name-to-address mapping is used to distribute load over a set of hosts.

in other words, doing another DNS lookup of the original DNS name only
looks like a good way to solve the problem if you don't look very deep.
 
now if you somehow got a host-specific (or narrower) identifier as a
result of setting up the initial connection (maybe via a TCP option),
and you had a way to map that host-specific identifer to its current IP
address (assume for now that you're using DNS, though there are still
other problems with that) - then you could do a different kind of lookup
to get the new IP address and use that to do a restart.

even then, it wouldn't help the numerous applications which don't have a
way to cleanly recover from dropped TCP connections.  (remember,  TCP
was supposed to make sure data were retransmitted as necessary and that
duplicated data were sorted out, provide a clean close, that sort of
thing.   once you expect apps to handle dropped connections they have to
re-implement TCP functionality at a higher layer.)
> The authors of RFC 4778 would take exception - they want to be able to
> log into the right place when everything is in flames. Apart from
> that, though, managing addresses through names would go a *long* way
> toward making renumbering easier. We already have many of those
and yet, it's quite clear that DNS as it currently exists is not
adequate for this.  not the query protocol, nor the data caching model,
nor the APIs, nor the security (at least as deployed), nor the names
that we're currently using, and probably not even the replication
mechanism.  which might be why the industry hasn't started consistently
using DNS for this.

Keith

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Sep 2007 06:19:33 +0400

On Sep 14, 2007, at 6:03 AM, Keith Moore wrote:

> perhaps, but it won't work reliably as long as there can be more  
> than one host associated with a DNS name, nor will it work as long  
> as DNS name-to-address mapping is used to distribute load over a  
> set of hosts.

well, this presumes that the application wants to get to the same  
instance of the peer, as opposed to getting to "an" instance of the  
peer. If the reason the session was lost was that the peer has gone  
out of service or is unreachable, insisting on the same instance of  
the peer has its down sides.

So there is probably some solution, as you suggest, such as having  
the application accept a peer-specific name for the purpose - if it  
has to retry, it can try the instance-specific name first, and if  
that fails, try the more general name.

Note that when I say "name", I am not limiting myself to a DNS name.  
I'm quite happy to see some other form of name if the apps folks want  
to design one, for all the reasons you cite. IMHO, some form of true  
directory, with unicode directly supported, would be a wonderful  
thing. I'm not the first to suggest that, as you know well. I'm  
waiting for those who understand those issues better than I do to  
make the proposal. Haven't seen it yet.

Have you ever used the term "layer violation", or heard it used by  
someone else? Having the application know the network layer address  
is just slightly worse than having it know what it's Ethernet address  
is or what port it is attached to. There are a few cases in which it  
has a real need to know. In all except those few, believe me, every  
whine I hear about renumbering is in my ears a whine about the layer  
violation. Make it go away, and the renumbering problem will be  
*much* easier to solve.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 Sep 2007 12:28:35 +1000

> name-to-address mapping is used to distribute load over a set of hosts.

	We already have the DNS hooks to distingish services from
	hosts.  We had them for the last 8 years.

	Some services actually use these hooks.
 
> re-implement TCP functionality at a higher layer.)

	Applications need to deal with TCP connections breaking for
	all sorts of reasons.  Renumbering should be a relatively
	infrequent event compared to all the other possible ways a
	TCP connection can fail.

	Until applications deal nicely with the other failure modes,
	complaints about renumbering causing problems at the
	application level are just noise.

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Sep 2007 23:34:48 -0400

>>> To my small mind, forcing a new DNS lookup in the event of a
Yes but SRV records weren't really meant to handle this case either. 
And they actually can make applications less reliable because they
introduce a new dependency on DNS (another lookup that can fail, in a
different zone and potentially on a different server, another piece of
configuration data that can be incorrect.)  What we'd really need is a
RR type specifically intended to map service names onto instance
ID+address pairs, and also a special query type that wasn't defined to
return all of the matching RR records, but would instead return a random
subset or a subset based on heuristics, and finally an instance ID to
address mapping service.  But arguably DNS isn't the right place to do
that at all - there should instead be a generic referral service at
layer 3 or 4.

Of course, part of the reason that people started using A records to
refer to multiple hosts was that a number of applications "just worked"
when they did that.  And I remember when people used to object loudly to
such things, and insist that a DNS name and a host name had to be the
same thing.  Anyway, this kind of overloading of A records has been such
a widespread practice for so long that I don't see it changing.  And
it's not as if we came up with a better way of doing things for IPv6
addresses.
> 	infrequent event compared to all the other possible ways a
Mumble.  Seems like the whole point of TCP was to recover from such
failures at a lower level.  And I remember how people used to say that
TCP was better than X.25 VCs (in part) because TCP would recover from
temporary network outages that would cause hangups in X.25.

I also don't have a lot of faith in "should be", not when I've seen DHCP
servers routinely refuse to renew leases after very short times, nor
when I've heard people say that a site should be able to renumber every
day.  

I used to try to get people to specify a minimum amount of time that a
non-deprecated address should be expected to be valid - say a day.  Then
application writers and application protocol designers would have an
idea about whether they needed a strategy for recovery from a
renumbering event, and what kind of strategy they needed.  But the only
people who seemed to like this idea were application area people. 
> 	application level are just noise.
in other words, one design error can be used to justify another?  sort
of like the blind leading the blind?

I see a significant difference between a design flaw in a particular
application that cripples that application, and a design flaw in a lower
layer that cripples all applications.

Keith

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Sep 2007 20:35:14 -0700

I remember Bill Clinton describing trying to develop an Internet standard like 'nailing jello to the wall'. 

________________________________

From: Iljitsch van Beijnum [mailto:[email-masked]]
Sent: Thu 13/09/2007 5:24 PM
To: Keith Moore
Cc: Tony Finch; IETF-Discussion
Subject: Re: Renumbering

Right.

!
interface Ethernet1
  ipv6 address autoconfig

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Sep 2007 00:01:15 -0400

> someone else? 
Occasionally :)
> Having the application know the network layer address is just slightly
> worse than having it know what it's Ethernet address is or what port
> it is attached to.
The flip side to this is that an immense amount of additional complexity
is required to truly make applications agnostic of lower layers. 
"Classic" TCP/IPv4 was a lot simpler and more deployable than it would
have been with a genuine ID/LOC split.  By making the assumption that an
address was "good enough" as an endpoint identifier, made implementation
on modest 1980s era hardware, not to mention slow networks, a lot more
practical.  And in the days before laptops and before the net got big
enough to make prefix aggregation necessary, this was a reasonable
assumption.

It seems that a lot of successful protocols were originally optimized
for deployability rather than optimized for longevity.   I suspect that
those protocols tend to be more successful, even in the long term, than
those that are initially optimized for longevity over deployability :) 
IPv4 is one example, DNS is another, HTTP is a third, I suspect BGP is a
fourth, and I'm sure there are many more.
> There are a few cases in which it has a real need to know. In all
> except those few, believe me, every whine I hear about renumbering is
> in my ears a whine about the layer violation. Make it go away, and the
> renumbering problem will be *much* easier to solve.
Well, every time I hear a whine in IETF about how people "should" or
"should not" do things a certain way, I ask myself whether this is
really a reflection of the network architecture's failure to solve some
important problem.  After all, if there were a better way to solve the
problem within the bounds of the architecture, people would probably
find it sooner or later.  Various practices that some of us might label
as dubious, including NATs, using IP addresses as authentication tokens,
using a single DNS name as a way to name a service that's actually
implemented by a large pool of hosts, or layer violations in general,
are all attributed to failures of the architecture or failures to
implement key features in our core protocols in a timely fashion.

So the reason people are writing applications that look at IP addresses
is because the network doesn't give them the tools that they need to
write good apps without looking at IP addresses.  (And they need to do
that even more in a NATted environment, or in an environment where hosts
have multiple source and/or destination addresses with different
characteristics, so it's not like the architecture is moving in a
direction to discourage layer violations).  It's a bit unrealistic to
expect those applications to change in order to solve the renumbering
problem, without providing those tools.   The incentives all favor
solving your own problem  (or making your own customers happy) even at
the risk of creating a problem for someone else, not to solve someone
else's problem even though it makes your own product less functional,
efficient, or reliable.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 Sep 2007 14:06:39 +1000

> when I've heard people say that a site should be able to renumber every

	So, someone misconfigured something.  Such misconfigurations
	usually get fixed fast.

	Getting the automation to the state where a daily renumber
	is possible is an achievable goal.  If we were doing that
	the long running apps would have been fixed long ago.  The
	fact that they aren't is more a matter of pressure than
	anything else.  That's why I started with a large period
	when I was suggesting that router and firewall vendors
	actually renumber themselves periodically.  It was to keep
	the problem in the management space rather than the application
	space.

	Have each vendor work on their part of the problem is the
	way to go.
 
> of like the blind leading the blind?

	No. People should work on making renumbering work efficiently.

	Using TCP failures at the application level as a excuse to
	no persue making renumbering work cleanly is just that, an
	excuse.
 
> layer that cripples all applications.

	Reconnect is a reasonable strategy for most applications.

	Holding a TCP session open in the presense of ICMP
	host/net unreachable is also a reasonable strategy.

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Sep 2007 00:31:25 -0400

> 	So, someone misconfigured something.  Such misconfigurations
In all of the cases where I've seen the DHCP thing happen, it was
deliberate.  And no, stupid network admins do not get fixed quickly.  At
least, not as a general rule.  The Peter Principle applies here as to
that profession as any other.

"address leasing" is one of the fundamental design flaws of DHCP.  Of
course, that's also water under the bridge.
> 	the long running apps would have been fixed long ago.
And if we could make the sun run backwards then we wouldn't need
streetlights.  Never mind those people on the other side of the world...

You want to make applications be slower, less reliable, and more complex
in order to make routing easier.  It's understandable that you might
feel that way, but don't expect everyone else to go along with it.   
Now if you find a way to solve the problems you are concerned about,
while also providing a truly viable solution for others,  Then we might
make some progress.  But mere handwaving won't cut it.  You have to make
a convincing case that your solution is comprehensive.

>   The
Yes, but firewall and router boxes are relatively easy to renumber,
because there are a smaller number of vendors and a smaller number of
interfaces.   Apps are much harder because they are so diverse.
> 	Have each vendor work on their part of the problem is the
Lots of apps vendors out there would have to come to some sort of
agreement.   Any purported solution had better be very versatile.  Of
course, a lot of the problem is a security problem.  Find a decent
(efficient, mostly reliable, easy to configure, and works across
administrative domain boundaries) way for hosts and nets to quickly
distinguish trustworthy traffic from untrustworthy traffic without using
IP addresses and you'd probably decrease application configuration of
addresses by an order of magnitude, maybe two.  (and also note that any
renumbering scheme can't been seen as weakening the relationship between
IP address and trustworthiness - that relationship is already too weak
as it is, but people will cling to it until there's something better)
> 	No. People should work on making renumbering work efficiently.
I don't disagree that it's worthy of further investigation.  I just
don't think that it's likely to succeed anytime soon, which is to say,
within a decade or maybe two.  Automated renumbering is not going to
alleviate the need for PI space or for the routing system to be able to
somehow handle large numbers of PI prefixes.  Something else might, but
not automated renumbering.  At least, that's what my intuition says. 
That doesn't mean don't try, it means don't depend on that being the
solution.
> 	Reconnect is a reasonable strategy for most applications.
Sounds very naive to my ears.

Keith

---

From: Greg Skinner <[email-masked]>
Date: Fri, 14 Sep 2007 05:08:04 +0000

> just network renumbering.

I know of one application that relied on long-lived DNS hostname to IP
mappings and ignored DNS TTLs.  Search engine crawlers cached the IP
addresses for pages that had been fetched, and used those addresses
even though the TTLs had expired.  This resulted in pages from
whatever content lived at those new IP addresses showing up
unexpectedly (incorrectly) in search engine results.  I don't know if
this has been fixed, but it's an example of application usage that
bypassed IETF recommendations for a presumably good cause (performance
reasons).

Another application with a similar reliance that is seeing some growth
is the use of IP addresses for geotargeting.  The geotargeting
provider attempts to determine the physical location of the IP address
for various purposes, such as to choose what ads to display.  I
imagine people on this list can see the flaws of doing this, but
nevertheless it persists.  I don't know how the geotargeting
providers plan to handle IPv6, but it's another example of how people
develop applications in ways that the IETF may not anticipate (because
they discourage such applications), but make migration to IPv6
difficult because of the installed base that depends upon specific
uses of IPv4 addresses.

--gregbo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Sep 2007 10:38:03 +0200

On 14-sep-2007, at 5:34, Keith Moore wrote:

> What we'd really need is a
> address mapping service.

Once again, I don't see why this would be a valid requirement.

And as I understand it, people who need this today typically host a  
service behind a single address and use a load balancer to spread  
incoming requests over a set of servers in such a way that the same  
client returns to the same server.

> failures at a lower level.

TCP protects you from lots of stuff, but it doesn't really let you  
recover from the remote endpoint rebooting, for example... (And  
something that's common in today's IPv4 deployments: NAT timeouts. I  
got bitten by that in Chicago, I think they were only a few minutes  
in my hotel, drove me insane because anything other than HTTP didn't  
work for long.)

---

From: Bill Manning <[email-masked]>
Date: Fri, 14 Sep 2007 02:15:57 -0700

> into limiting their thinking to the legacy IPv4 deployment model. 
... {elided}
> cost savings will turn on them as a sizable cost when changes become

	beating this dead horse...
	actually, David is profoundly wrong.  IPv6 is an entirely
	new address family - it has erie similarities to IPv4, but
	is not backward compatable.

--bill

---

From: <[email-masked]>
Date: Fri, 14 Sep 2007 11:20:43 +0100

>  I remember Bill Clinton describing trying to develop an Internet
standard like 'nailing jello to the wall'.  
 
Actually he said that trying to censor the Internet was like trying to
nail jello to the wall. See the press release from the U.S. Embassy in
China where he made the remark in the context of the Great Firewall of
China.
 
http://www.usembassy-china.org.cn/press/release/2000/clinton38.html
 
With hindsight, and knowing the many ways in which people have subverted
the Great Firewall he was quite right. In the IETF context, I think it
proves the rule of "be conservative about what you send, be liberal
about what you accept" because the jello comes from the way people
actually use IETF technology in the real world.
 
The IETF is incapable of designing a solution to a problem. We can only
design protocols which create possibilities for the real solution
designers to leverage. Engineers like to have end-to-end control of a
problem in order to design end-to-end solutions but that is often not
possible in the real world, and especially not possible when your work
is restricted to the vicinity of layer 3.
 
--Michael Dillon

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Sep 2007 07:24:21 +0400

hmm. I'm not sure you're talking about the same thing.

DNS is a rendezvous protocol. I I want to open a session with <foo>,  
I translate <foo>'s name to an adddress and open a TCP connection.  
Having done so, the application doesn't need either the name or the  
address as long as the session is stable. It uses its socket.

Now, if the session takes a hike, there are issues. If you're using  
SCTP, those are relatively fixable (draft-ietf-tsvwg-addip-sctp); in  
TCP, at least at this point, one closes and reopens the socket with a  
new address. What is needed is knowledge of the new address, which in  
the internet draft comes from the peer through the socket.

So in SCTP there actually is a solution, and DNS TTLs are not  
relevant to the question.

Yes, if the name is retained and not re-translated on a session  
failure even though the TTL has expired, that's a problem. It's a  
different problem.

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Sep 2007 07:48:45 -0400

>> What we'd really need is a  RR type specifically intended to map
>> service names onto instance  ID+address pairs, and also a special
>> query type that wasn't defined to  return all of the matching RR
>> records, but would instead return a random subset or a subset based
>> on heuristics, and finally an instance ID to address mapping service.
yes, that's typically how it's done today, because it tends to work
better than playing games with DNS.  Though part (not all) of the reason
it works better is that DNS wasn't designed to support this.
>>>     Applications need to deal with TCP connections breaking for all
>>> sorts of reasons.  Renumbering should be a relatively infrequent
>>> event compared to all the other possible ways a TCP connection can
>>> fail.
> recover from the remote endpoint rebooting, for example... 
well, duh.   if the endpoint fails then all of the application-level
state goes away.  TCP can't be responsible for recovering from the loss
of higher-level state.  but we're not talking about endpoint failures,
we're talking about the failure of the network.  TCP is supposed to
recover from transient network failures.  it wasn't designed to cope
with endpoint address changes, of course, because the network as
designed wasn't expected to fail in that way.
> (And something that's common in today's IPv4 deployments: NAT
> timeouts. I got bitten by that in Chicago, I think they were only a
> few minutes in my hotel, drove me insane because anything other than
> HTTP didn't work for long.)
given that NATs violate the most fundamental assumption behind IP (that
an address means the same thing everywhere in the network), it's hardly
surprising that they break TCP.

Keith

---

From: Florian Weimer <[email-masked]>
Date: Fri, 14 Sep 2007 13:59:46 +0200

> 	there are spots where it is not automated then they should

It's not possible to automatically renumber firewall configurations in
different administration domains (quite deliberately so), and you
can't take your mail reputation with you (at least not completely).

---

From: <[email-masked]>
Date: Fri, 14 Sep 2007 13:15:36 +0100

> given that NATs violate the most fundamental assumption 
> behind IP (that an address means the same thing everywhere in 
> the network), it's hardly surprising that they break TCP.

Has RFC 2526 been deprecated? 

-- Michael Dillon

P.S. RFC 2526 - Reserved IPv6 Subnet Anycast Addresses

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 14 Sep 2007 14:20:20 +0200

On Thu, Sep 13, 2007 at 10:11:34AM -0700,
 Tony Li <[email-masked]> wrote 
 a message of 44 lines which said:

> As a practical matter, these things are quite doable. 

Yes.

> This is not theoretical, I've worked with all of the above.

Yes. But the point is that many, probably most sites do not have such
a methodology. Configurations are maintained by hand, text files are
not generated from a database by a program, IP addresses are
everywhere (think of documentation), etc.

Let's try to improve things: your post is a good sketch for a BCP
describing how organizations should handle IP addresses to make
renumbering as painless as possible. Why not making an I-D from it?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Sep 2007 10:59:20 -0400

> 	did you do that in the past?

   Each of my Sandelman/Xelerance locations switch ISPs about every 3-4 years.
   There are presently 5 such locations, so there is a renumber about every 
year.  I am about to renumber my SOHO, which is an IPv4/25 in in PA space.

   Ironically, my IPv6, which comes through a tunnel, won't need to be 
renumbered. (One of the reasons I liked Tony Hain's geographical assignment. 
Tunnels don't bother me)

   In IPv6, we would be quite happy to always have two IPs on every host 
(even though Linux does source address selection poorly, Itojun's code in BSD 
does very well).
   One PI-ish address which never has to change, which is kinda-site-local,
but might not get ultra-high-bandwidth, and one PA-ish address whicuests start coming in
marshall> that do _not_ want IPv4 space. This should be encouraged, not
marshall> discouraged.

   I'm here. I'm bit more clueful about ARIN process than average.
   Most businesses would have no idea what to do once ARIN said no.
   Or, they'd just lie.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Sep 2007 10:59:20 -0400

In IPv6, we would be quite happy to always have two IPs on every host 
(even though Linux does source address selection poorly, Itojun's code in BSD 
does very well).
   One PI-ish address which never has to change, which is kinda-site-local,
but might not get ultra-high-bandwidth, and one PA-ish address which is much 
faster.
   PI addresses don't have to imply centralized NAT to get out. We can do it 
in the hosts instead...
   That's nicely what shim6 is doing, hmm.

   Renumbering is not fun. IPv6 doesn't make it easier, since the DNS dynamic 
update stuff never really got fully implemented. (specified, yes, I think)

   Wearing my XDS hat, the company survives entirely using rfc1918 internally,
with a dozen IPv4 NATs + VPNs.  We use all of 192.168.0.0/16 for enterprise 
production. Testing occurs in 10.x. This leaves 172.16/20 for my customer 
facing networks.  Not enough, so I will have to re-use addresses. Thus my 
interest in IPv6.
   Using a single prefix massively simplifies the VPNs.  That's why 
enterprises want a single PI-ish prefix.

   The shim6 multiple address possibilities is one reason why I'm vague about 
whether or not I need to multi-home my address space.
   I suspect that I *won't* need to in the end -- I'll be able to use shim6.

h is much 
faster.
   PI addresses don't have to imply centralized NAT to get out. We can do it 
in the hosts instead...
   That's nicely what shim6 is doing, hmm.

   Renumbering is not fun. IPv6 doesn't make it easier, since the DNS dynamic 
update stuff never really got fully implemented. (specified, yes, I think)

   Wearing my XDS hat, the company survives entirely using rfc1918 internally,
with a dozen IPv4 NATs + VPNs.  We use all of 192.168.0.0/16 for enterprise 
production. Testing occurs in 10.x. This leaves 172.16/20 for my customer 
facing networks.  Not enough, so I will have to re-use addresses. Thus my 
interest in IPv6.
   Using a single prefix massively simplifies the VPNs.  That's why 
enterprises want a single PI-ish prefix.

   The shim6 multiple address possibilities is one reason why I'm vague about 
whether or not I need to multi-home my address space.
   I suspect that I *won't* need to in the end -- I'll be able to use shim6.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 14 Sep 2007 09:38:36 -0400

> when it was designed, had all the little details worked out?

No, of course not. But the analogy is misleading, IMO. When IPv4 was
designed, it was used by a _very_ small set of players and very few
people really depended on it. Making changes was easier. Experimenting
with a "play" system is always easier.

Today, the Internet is part of the world's basic infrastructure. We're
kind of past the point  of being able to say "let's just bet the farm
on this, and see if we can work out the open issues later".

> encourages protocol design to be directed by corner cases.

This is sometimes very true.  But I disagree that this is the reason
we haven't done an ID/Loc split yet. At the end of the day, we have
yet to see a real design fleshed out in enough detail that folk can
honestly say "yep, I think we can make this work in practice and I
think I understand how the pieces will all fit together". And I'm
talking about _all_ the pieces, not just the 80% that are the easiest
and we know how to do.

> In this particular case, it isn't even clear to me there is
> agreement on what the problem we're trying to solve actually is.

Yes, this is a key issue (like in so many cases). People are all over
the map in terms of (picking ID/loc as an example), how frequently the
mapping needs to be able to change. Once a week? Every few minutes?
Quickly enough for mobility, etc.  These sorts of questions are
critical to answer before focussing too much on solutions.

> be doomed.  The IRTF is, after all, focused on research.

If there is engineering work to do, make the case it is ready for the
IETF. Personally, I think the ID/Loc work is still in that gray area
between engineering and research. Ready for engineering means we know
how to do it, there are no hard problems to still work out. We just
need to agree on a standard way to do something.

On the other hand, if we don't know how to do a scalable mapping part
yet, that sounds like research to me. (Insert long-running discussion
here about how DNS is or is not good enough to provide this
functionality.)
 
> I can imagine the people in the IRTF contributing towards a solution
> but that isn't where a solution will come from.  Given real world

Yep. But I would hope that the research side can do the work that
leads to answering the previous question with an answer of "yep, I
think we know how to this and can make it work and just need to agree
on the bits."

Thomas

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 Sep 2007 23:49:39 +1000

> can't take your mail reputation with you (at least not completely).

	Actually it is.  You just are not willing to do it.  It is
	100% possible to do this automatically.  It just requires
	the chains of trust to be setup.
 
	If you live in a dynamic world, you setup those chains.

	Just don't say that renumbering can't be automated because
	it can.

	Mark

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Sep 2007 09:57:56 -0400

> 	the chains of trust to be setup.
you seem to be thinking that this is a purely technical problem.  it's not.

and there are valid reasons for keeping humans in the loop, and slowing
things down, when trust is involved.

Keith

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 14 Sep 2007 09:25:24 -0500

Well...

> you seem to be thinking that this is a purely technical problem.  it's 

I can go there, on this point ...

> things down, when trust is involved.

... and i can go that direction, on this point, but not all the way there. 
It is possible to "keep a human in the loop" without doing so in real time.

As Michael pointed out, we trust BGP4 with a lot (see the many NANOG 
presentations on why this can be exciting, but we do), for many networks, 
including the largest networks.

BGP4 does involve humans, because you can't do policy-based routing and 
policy-based traffic engineering without a human telling BGP4 "yes, that 
WOULD be the shortest path, but don't use it for THIS traffic because of 
economic reason X".

But once humans tell BGP4 what the policy is, we pretty much trust the 
protocol to "do the right thing" in selecting paths out of an AS, reflecting 
current connectivity, without human involvement, until something goes 
breathtakingly wrong.

At least, that's the way it seems to me.

Spencer

---

From: <[email-masked]>
Date: Fri, 14 Sep 2007 15:47:56 +0100

> 	Just don't say that renumbering can't be automated because

You repeatedly wave your hands and say that it can be done but you
refuse to provide a single reference to a protocol or implementation
which makes this possible. The reason people are arguing against you is
because we do not know of a case study where this is successfully being
done. We don't know of any software which is successfully being used to
renumber firewalls.

Please point us to specific references, conferences, case studies, RFCs,
etc.

--Michael Dillon

---

From: Tony Finch <[email-masked]>
Date: Fri, 14 Sep 2007 18:38:07 +0100

On Thu, 13 Sep 2007, Keith Moore wrote:

> that spans several transport lifetimes.

TLS session caches. HTTP cookies. FTP control connections.

Apps that want to deal with concurrent data streams within one user's
session currently have to establish and authenticate multiple TCP
connections (e.g. HTTP, IMAP) or re-implement TCP's multiplexing and
windowing at the application level (e.g. BEEP, ssh).

A session layer would allow an app to establish a security context once
then re-use it when establishing new transport connections, so that
re-connecting can be cheap and concurrent data streams can be simple.
Unfortunately TCP doesn't share congestion information between
connections, which penalises new bulk-data streams and requires
workarounds at the application level (e.g. HTTP/1.1 persistent
connections).

(I have been thinking along similar lines to Karl.)

Tony.

---

From: Tony Finch <[email-masked]>
Date: Fri, 14 Sep 2007 18:45:12 +0100

> Then pretty much every IP-aware application ever written is broken.

Not entirely. Applications that use short-lived connections are generally
OK (so long as the implementation talks to its resolver in a sensible
way - many screw this up). This covers HTTP and most email protocols.
Many apps with long-lived TCP connections can recover OK from a broken
connection. Long-lived UDP associations can be a problem - renumbering an
NTP server is a pain.

Tony.

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Sep 2007 13:56:21 -0400

> TLS session caches. HTTP cookies. FTP control connections.
okay fine (at least for the first two) but should that information be
managed by the application, or at a lower layer?  particularly if it
needs to be shared among multiple instances of a service that may reside
on different hosts?
> windowing at the application level (e.g. BEEP, ssh).
I actually don't think that having multiple concurrent TCP connections
between two peers is a bad thing.   sure we could have a transport
protocol that provided multiple streams, but why bother when concurrent
TCP connections works pretty well?
> workarounds at the application level (e.g. HTTP/1.1 persistent
mumble.  I don't have a problem with multiple TCP connections, but OTOH
I think that using TCP close for framing is bad application design.   so
I don't view persistent connections in HTTP as a workaround, I view it
as fixing a design flaw in HTTP/1.0.

---

From: David Conrad <[email-masked]>
Date: Fri, 14 Sep 2007 10:59:26 -0700

Tony,

> into limiting their thinking to the legacy IPv4 deployment model.

I'm not particularly interested in getting into a "Yes it is! No it  
isn't!" debate.  I will merely point out that IPv6 has been  
implemented and is being deployed as IPv4 with more bits.  As I said,  
you can argue it shouldn't be this way, but reality often sucks.

I might suggest that the reason why major core infrastructures like  
the telephony system, utility grids, etc. are often hodgepodges of  
hacks and kludges is because the business case to throw out  
successful deployment models and existing plants is difficult to  
make.  And when you do, you generally want to insure a high level of  
backwards compatibility so that you don't have to change everything  
to make use of the new bits.

> There are way too many arguments
> differently between the versions.

Can you point to one widely used application, API, or operating  
system (that doesn't require manual intervention) that supports this?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Fri, 14 Sep 2007 11:14:16 -0700

Dave,

On Sep 13, 2007, at 5:43 PM, Dave Crocker wrote:
> That sort of equivalence statement applies when the new version is  
> a minor upgrade to the previous, rather than require massive  
> changes to the infrastructure AND to client applications. Having to  
> run parallel stacks, having substantial changes to administration  
> and operations,

I believe that _if_ there was IPv6 support in network management,  
provisioning, back end systems, CPE, router ASICs, etc., there  
wouldn't need to be significant change to administration or  
operation.  You would obviously need to change systems to deal with  
128 bit values in ACLs and filters, etc., but that should be a simple  
SMOP.  In terms of provisioning, the only change that _might_ be  
necessary is changing the default customer allocation from a /28 (or  
whatever) to a /48.  This might imply a change in some aspects of  
business models for those folks who charge extra for IP addresses,  
but I can't really see that as being that big a deal.

Of course what turns out to be a big deal is getting to the point  
where that starting "if" statement passes.  However, the point of my  
statement is that in reality, IPv6 must be treated pretty much the  
same as the thing is it attempting to replace.  If not, you're  
requiring 1 billion people to change the way they do things and we  
have given them (a) no reason to and (b) no real tools to do it. This  
won't work.

> and having major changes to the minimum required set of  
> capabilities is more than just a few more bits.

Can you give an example of what you mean by this?

Thanks,
-drc

---

From: David Conrad <[email-masked]>
Date: Fri, 14 Sep 2007 11:30:49 -0700

On Sep 13, 2007, at 6:01 PM, Fred Baker wrote:
> names, and maintained no knowledge in the application of what  
> address was used.

I always thought an opportunity was missed when coming up with the  
socket interface for IPv6 in that we didn't push the management of  
the address down to the kernel, having the kernel return a  
'handle' (like a file handle) in struct sockaddr_in instead of the  
bit pattern that was actually used on the network.  We might even  
have been able to use the class E address space as the handle thereby  
making the upgrade to IPv6 much more transparent to applications than  
it is now.

Water under the bridge.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Fri, 14 Sep 2007 11:34:15 -0700

Bill,

> beating this dead horse...

The official IETF state sport.

> actually, David is profoundly wrong.

Frequently.

> IPv6 is an entirely new address family - it has erie similarities  
> to IPv4, but is not backward compatable.

The "with more bits" part wasn't an offhand comment.

Regards,
-drc

---

From: Tony Finch <[email-masked]>
Date: Fri, 14 Sep 2007 19:54:34 +0100

> TCP connections works pretty well?

I agree, except that "pretty well" is a bit crappy when every connection
has to re-establish authentication and encryption - which is what drives
some protocols to implement their own multiplexing.

> as fixing a design flaw in HTTP/1.0.

I agree, especially because some software has problems telling the
difference between clean and dirty closes. However there's a latency /
efficiency trade-off, and TCP pushes you towards pipelining multiple
transactions down a few connections even when a more natural design
might have greater concurrency. mumble.

Tony.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Sep 2007 12:43:33 -0700

David,

David Conrad wrote:
>> That sort of equivalence statement applies when the new version is a 
>> minor upgrade to the previous, rather than require massive changes to 
>> the infrastructure AND to client applications. Having to run parallel 
>> stacks, having substantial changes to administration and operations,
> 
> provisioning, back end systems, CPE, router ASICs, etc., there wouldn't 

A rather large IF, don't you think?  Something like "IF everyone in the world 
wanted peace, peace would be easy to achieve."

That's the lesson of the installed base:  Making a change to the 
infrastructure is ALWAYS a very big deal indeed.

Unless I've missed something rather basic, in the case of IPv6, very little 
attention was paid to facilitating transition by maximizing interoperability 
with the IPv4 installed base.

> need to be significant change to administration or operation.  You would 
> obviously need to change systems to deal with 128 bit values in ACLs and 
> filters, etc., but that should be a simple SMOP.  In terms of 

Programming tends to be the smallest issue for large scale transitions.  Admin 
and ops tend to be the large concerns. So once your SMOP is taken care of, 
there is the not-so SMO admin and ops for the entire Internet, with what seems 
to be little incremental benefit for incremental adoption.

Incremental benefit for incremental adoption has typically been the key to 
gaining large-scale adoption, particularly for improvements to an entrenched 
service.

> Of course what turns out to be a big deal is getting to the point where 
> that starting "if" statement passes. 

Right.

> However, the point of my statement 
> is that in reality, IPv6 must be treated pretty much the same as the 
> thing is it attempting to replace. 

In a standalone sense, perhaps.  That is, in terms of conceptual issues, 
perhaps.  Alas, since you are in the ops world, you know that there is rather 
a large difference between concept and practice.

IPv6 must modify decades of installed base software, management and use and it 
is pursuing this as a wholly parallel software, admin and ops effort.

>> and having major changes to the minimum required set of capabilities 
>> is more than just a few more bits.
> 

I'd be glad to be disabused of this understanding:  IPv6 is is pursuing this 
as a wholly parallel software, admin and ops effort.  That it re-uses some 
code is nice but isn't the issue.

   *    Entirely new IP Address allocations, starting with an RIR, moving on 
to all infrastructure entries and including DNS, and parallel operations of 
such things as routing, Neighbor Discovery protocols, IPv6 Stateless Address 
Autoconfiguration, ICMP.  (Maybe more?)

   *   Dual, simultaneous admin and ops activities, for IPv4 and IPv6. That's 
a big deal.

d/
-- 

   Dave Crocker

---

From: Greg Skinner <[email-masked]>
Date: Fri, 14 Sep 2007 20:34:34 +0000

On Fri, Sep 14, 2007 at 07:48:45AM -0400, Keith Moore wrote:
> [sorry, lost attribution here]

When I was first learning about networking back in the mid-1980s, I
worked on a project involving mobile hosts.  The hosts were permitted
to change their IP addresses, but TCP-level connectivity needed to
remain intact.  The loss of a route to some network (or host within
that network) might trigger an ICMP unreachable, but the applications
(e.g. telnet, ftp) needed to be rewritten not to close in such a
situation.

It seemed like a reasonable thing to do to treat something like a net
or host unreachable as a transient condition, and allow the
application to proceed as if nothing serious had happened.  When
routing connectivity could be restored quickly, the maintained state
at both ends of the TCP connection would allow the application to
proceed normally.  However, this practice doesn't seem to have made it
into the application-writing community at large, because lots of
applications fail for just this reason.  I wonder if even writing a
BCP about this even makes sense at this point, because the application
writers (or authors of the references the application writers use) may
never see the draft, or even be concerned that it's something they
should check for.

> surprising that they break TCP.

After installing a NAT firewall/router, I noticed my ssh connections
would drop when left idle for awhile.  That never happened before -- I
could go away from my machine for hours, and as long as client and
server machines were up, with no network dynamics, everything would
work fine when I returned.  But is it TCP itself that's failing, or
ssh interpreting the timeout as a non-transient condition, and telling
TCP to close?

I think a reasonable compromise for application writers who are
concerned about allocating resources to connections that might really
need to close (e.g. because the remote end really did crash, or there
was a really long timeout), is to allow the user to specify the
behavior for the application to take when a level 3 error condition
occurs.

--gregbo

---

From: Florian Weimer <[email-masked]>
Date: Fri, 14 Sep 2007 23:32:28 +0200

* Mark Andrews:

> 	Actually it is.  You just are not willing to do it.

Our customers and business partners aren't willing to do this.  Even
"ICANN doesn't allow it" as an execuse would be essentially correct.

>       It is 100% possible to do this automatically.  It just requires

Yeah, and this chain of trust is simply not there, otherwise there
wouldn't be firewalls in the first place, just VPNs.

> 	Just don't say that renumbering can't be automated because

Sure, using proprietary protocols and whatnot.  Rather Utopian if each
customer buys from a different vendor.

---

From: David Morris <[email-masked]>
Date: Fri, 14 Sep 2007 14:55:14 -0700 (PDT)

> ssh interpreting the timeout as a non-transient condition, and telling

If that was truely the only change, then you have encountered one of the
idiot firewalls (which includes iptables on linux) which feel compelled to
drop idle connections from their connection state map. In the case of one
system I manage (with no NAT!), I got around the frustration by setting
the system tcp keep-alive interval. Some firewalls and NAT devices may be
configured to do this nasty ... some only when resources are constrained.

A temporary baby firewall (netgear) on my home network timesout but since
it isn't in my normal path, I live with it.

Another candidate is a bash feature which can be set to timeout after idle
time. But that leaves a message and in any case doesn't relate to your
change.

Dave Morris

---

From: Mark Andrews <[email-masked]>
Date: Sat, 15 Sep 2007 08:52:57 +1000

> things down, when trust is involved.

	Actually I doubt that there really are valid reasons other
	than to initiate the change.  You can send the notification
	of change automatically.  It can be acknowledge automatically.
	Whether it is approved at the other site automatically
	doesn't matter.  You can even send reminders automatically
	only escalating to humans when there is a failure to respond
	after a period of time.

	We automate similarly trust relationships all the time.

		I've added/removed prefix <value>.
		Please update your firewall to reflect this.

	This is not a hard message to send automatically.  To process
	automatically.  To acknowledge that the change has been
	performed automatically.  It's a update to a existing
	relationship.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Sat, 15 Sep 2007 09:35:01 +1000

> > =20
> >=20

	I get renumbered in IPv4 today.

	I have my dhcp client fire off a reconfig script.

	That script

	* reconfigures the IPv6 tunnel to use the new address.
	  It does *both* ends.

	* It notifies all the remote parties that need to know thar
	  the remote address has changed as they need to change
	  configuration details.  Thise includes getting firewalls
	  updated and DNS servers updated.

	Yes it is ad-hoc but it also proves that it can be done.

	I'm lazy.  I have better things to do that type email notices
	whenever my IP address changes.  Historically that is every 3-6
	months.

	Mark

---

From: David Conrad <[email-masked]>
Date: Fri, 14 Sep 2007 17:05:46 -0700

Mark,

> 	I get renumbered in IPv4 today.

I suspect there is probably a question of scale here.

I wouldn't be surprised that a small home network with a limited  
number of subnets and systems could be automatically renumbered.

I would be surprised if a network of any appreciable size could be.   
Particularly one that has non-trivial relationships with other networks.

How many subnets and devices are there on the network you  
automatically renumber?

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Sat, 15 Sep 2007 12:06:26 +1000

> How many subnets and devices are there on the network you  

	The point was to demonstrate that it can be done.

	It just requires people to be willing to do this.

	On a home network you do most of the things by hand.
	In a enterprise you use a network management station
	to do the work for you.  Having that management station
	send out notifications to third parties is really not
	a big ask.

	Mark

---

From: Bill Manning <[email-masked]>
Date: Sat, 15 Sep 2007 00:53:56 -0700

> 	send out notifications to third parties is really not

	interestingly, some software vendors ship w/ license
	keys tied to IP addresses... particularly for enterprise
	level stuff.  not so easy to update in my experience.

	then there is the thorny DNS problem of updating the
	root hints file.  If DNS is so automated, why is this
	still a big problem?  (noting that the legacy address
	for "B" is still getting 300qps, nearly three YEARS
	after it was turned down)

	David is correct, scale does have its own set of renumbering
	problems.  While i believe you, i think your confidence
	is based on some naieve assumptions.

--bill

-- 
--bill

---

From: Mark Andrews <[email-masked]>
Date: Sun, 16 Sep 2007 00:08:30 +1000

> 	level stuff.  not so easy to update in my experience.

	I've always thought that practice to be STUPID.  It was
	stupid 15 years ago and it is still stupid today.  Yes
	I've had to renumber sites with keys tied to IP addresses.

> 	after it was turned down)

	Once we get the root, net and root-server.net signed, writing
	out new hints is can be done with a high degree of assurance
	that the contents reflect reality.  Sure there will still
	be old boxes that continue to try to talk to B but the new
	boxes won't and eventually all the old boxes will go, due
	to component failure if nothing else.
 
> 	is based on some naieve assumptions.

	I'm not saying scale doesn't have problems.  Automation
	however is the solution to those problems.  That's why
	management stations were invented.

	Mark

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Sep 2007 07:51:02 -0700

At 12:08 AM +1000 9/16/07, Mark Andrews wrote:
>	stupid 15 years ago and it is still stupid today.

The fact that you as an individual thing it is stupid (in uppercase 
or lowercase) is irrelevant. Several large vendors disagree with you. 
Their customers have gotten used to dealing with this and do not 
consider it so onerous as to change to the other large vendors who 
use a different licensing scheme.

--Paul Hoffman, Director
--VPN Consortium

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 15 Sep 2007 17:08:29 +0200

> or lowercase) is irrelevant. Several large vendors disagree with  
> you. Their customers have gotten used to dealing with this and do  
> not consider it so onerous as to change to the other large vendors  
> who use a different licensing scheme.

If we can't agree that this practice is stupid, can we at least agree  
that we can't let this impose restrictions on what we can and can't  
do within the IETF?

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Sep 2007 08:15:48 -0700

At 5:08 PM +0200 9/15/07, Iljitsch van Beijnum wrote:
>If we can't agree that this practice is stupid, can we at least 
>agree that we can't let this impose restrictions on what we can and 
>can't do within the IETF?

Certainly. Every vendor who ties a license to an IP address has 
already had to deal with customers who change IP addresses. I doubt 
that Bill's mentioning of this practice was meant to say "therefore 
we can never do anything that would cause renumbering".

--Paul Hoffman, Director
--VPN Consortium

---

From: Terry Gray <[email-masked]>
Date: Sat, 15 Sep 2007 09:42:00 -0700 (Pacific Daylight Time)

On Sat, 15 Sep 2007, Paul Hoffman wrote:

> Certainly. Every vendor who ties a license to an IP address has already had to
> deal with customers who change IP addresses. I doubt that Bill's mentioning of
> this practice was meant to say "therefore we can never do anything that would
> cause renumbering".

On the other hand, if you develop a system that forces enterprises to 
renumber, then you GUARANTEE that a large set of them will find a way 
to avoid (or at least take control of their own) renumbering, e.g. 
NAT --for many reasons that have already been cited in this thread, 
and some that have not been.

Example: Fred mentioned that it would be nice to just use some form of 
host names, instead of addresses, but in the world I live in, MANY 
groups are geographically dispersed and want Traffic Disruption 
Appliances on each of their subnets to allow unrestricted flow among 
their *blocks* of addresses --they certainly would not want to either 
a) manage large lists of explicit host addresses *or* names, or b) 
change their complex firewall rules whenever someone sez let's do the 
Renumber Drill!  (Is that perimeter protection model fundamentally 
flawed?  Of course it is, just like NAT is.  Both observations will 
not change the reality of their continued use.  The question should 
be: what will?

Note also, for fans of homogeneous networks and single network 
management stations, that a single AS may have hundreds of autonomous 
management domains within it.  As others have said, this is not 
entirely a technology problem.

-teg

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 15 Sep 2007 19:17:26 +0200

On 15-sep-2007, at 18:42, Terry Gray wrote:

> Renumber Drill!

[...]

> As others have said, this is not entirely a technology problem.

Usually the reason for that is that the technology isn't good enough  
to solve the problem fully, which may or may not be a fundamental,  
unsolvable issue.

As far as making IP addresses less visible than they are today, I  
think there is a lot we can do. My day job involves creating router  
configurations (in networks that aren't large enough to have  
sophisticated management systems). I have to put addresses rather  
than names in router configurations because when there is trouble  
with the network, it may not be possible to ask the DNS to translate  
a name into an address. (And there's the security issues.)

The way the DNS works today is that you ask it for a mapping, and it  
returns you that mapping along with a time to live value. After that,  
you need to forget the mapping and consult the DNS again. A system  
that would work much better in router/firewall/etc configurations is  
a system where you may ask the name resolving system for a mapping to  
get you started, but once you have your mapping, you get to keep it  
until the name resolving system contacts YOU and tells you something  
has changed.

Such a name resolving system would have to be under explicit  
administrative control, so that when my vendor that needs access to  
something deep inside the firewalled core of my network changes his/ 
her address I as an administrator get to see that and execute a  
policy (verify certificates, make a phone call, change vendors). The  
issue of unreachable root servers etc becomes moot because in that  
case you just keep running with the existing mapping information.

Working with names is much easier than with addresses because you can  
easily allow *.example.com rather than all the individual addresses/ 
prefixes that Example, Inc uses around the world.  
blah.vendors.example.com could also point to mothership.blah.com so  
you only need to allow *.vendors.example.com rather than a long list  
of vendors.

---

From: Bill Manning <[email-masked]>
Date: Sat, 15 Sep 2007 15:32:27 -0700

> 	I've had to renumber sites with keys tied to IP addresses.

	stupid or not, it exists and is not ammenable to automation.
	
> 	management stations were invented.

	automation can augment renumbering events, but until we
	have a fundamental change in architecture, renumbering will require
	human intervention and will always be disruptive.

--bill

---

From: Mark Andrews <[email-masked]>
Date: Sun, 16 Sep 2007 12:17:21 +1000

> 	stupid or not, it exists and is not ammenable to automation.

	Why isn't it?  It's just one more message for the management
	station to push out.
 	
> 	human intervention and will always be disruptive.

	It doesn't take a change in architecture.  We have the
	technology today to remove the need to tie anything to specific
	IP addresses.  It just requires the willingness to use it.

	Mark

---

From: Bill Manning <[email-masked]>
Date: Sat, 15 Sep 2007 21:14:44 -0700

> 	Why isn't it?  It's just one more message for the management

	notifcation sure...  getting the other side to re-issue the license
	with the new IP's (which the MS has to figure out what they are on 
	its own, wiht the kewl AI-based smarts that it has) - and then
	getting the new code installed/configured ... all under the automated
	hands of "master control".... is a different set of considerations.

> 	IP addresses.  It just requires the willingness to use it.

	simple assertion does not make it so.  perhaps we should make a checklist
	and see which things meet your criteria.  (my assertion that location/ID
	overload is built in to both IPv4 and IPv6 seems to be born out by the
	specs, documentation, and commentary over the past 25 years ... and that
	until one can cleanly seperate the two, that renumbering will be difficult
	should also be tested)  I have provided TWO cases where renumbering is
	is difficult to automate - i'm sure i can find others.  I beleive your
	claim (oblique as it may be) is that the DNS name is the long-term persistant
	identifier...  I tried to make that claim a decade ago and was persuaded
	(eventually) otherwise.  Time to dig through the archives to see if that
	logic still holds true.

-- 
--bill

---

From: "Michel Py" <[email-masked]>
Date: Sat, 15 Sep 2007 21:32:21 -0700

I have to say that this latest thread about renumbering has been
entertaining; besides the usual trolls I have never seen as many
un-experienced, incompetent, or both, contributors who think just
because they have read something about it in a magazine while waiting at
the dentist entitles them to an opinion.

And no, I don't have to be politically correct. Unlike most of the bozos
mentioned above, I have actually been in the trenches renumbering
real-world networks.

Michel.

---

From: <[email-masked]>
Date: Sun, 16 Sep 2007 12:50:19 +0100

> I'm not particularly interested in getting into a "Yes it is! 
> No it isn't!" debate.  I will merely point out that IPv6 has 
> been implemented and is being deployed as IPv4 with more 
> bits. 

If more people would get involved in developing a best practices
document for IPv6, perhaps through a wiki like www.getipv6.info then
this would be less of a problem.

We need some document to point to in order to explain why IPv6 is not
just IPv4 with more bits.

--Michael Dillon

---

From: <[email-masked]>
Date: Sun, 16 Sep 2007 14:46:52 +0100

>  I wonder if even 
> writing a BCP about this even makes sense at this point, 
> because the application writers (or authors of the references 
> the application writers use) may never see the draft, or even 
> be concerned that it's something they should check for.

I think that it does make sense to write a draft because the growing
effort to roll out IPv6 is causing lots of people to review their
applications and how they communicate on the network. I would expect
that some percentage of those applications would end up being changed if
such a draft were available.

--Michael Dillon

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 16 Sep 2007 16:17:44 +0200

On 14-sep-2007, at 22:34, Greg Skinner wrote:

> When routing connectivity could be restored quickly, the maintained  
> state
> applications fail for just this reason.

What I experienced is that when logged in to a Unix machine from a  
Windows machine, if the address went away or the connectivity was  
lost and an ICMP unreachable came back, the Windows box would  
terminate the session, while pretty much everything else would keep  
the session alive for some time so you could put the address back /  
restore connectivity and the session was still there if the other  
side hand't timed out / reset.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 17 Sep 2007 10:36:25 +1000

> 	hands of "master control".... is a different set of considerations.

	Actually if they want to tie the licence to a address, a ULA
	would provide exactly the same level of assurance they get
	today and make it independent of PA renumber events.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 17 Sep 2007 12:02:57 +0300

> might have greater concurrency. mumble.

You might be interested in Bryan Ford's SST paper from this year's  
SIGCOMM:

Structured Streams: a New Transport Abstraction. Bryan Ford. ACM  
SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. http:// 
www.brynosaurus.com/pub/net/sst-abs.html

Abstract: Internet applications currently have a choice between  
stream and datagram transport abstractions. Datagrams efficiently  
support small transactions and streams are suited for long-running  
conversations, but neither abstraction adequately supports  
applications like HTTP that exhibit a mixture of transaction sizes,  
or applications like FTP and SIP that use multiple transport  
instances. Structured Stream Transport (SST) enhances the traditional  
stream abstraction with a hierarchical hereditary structure, allowing  
applications to create lightweight child streams from any existing  
stream. Unlike TCP streams, these lightweight streams incur neither 3- 
way handshaking delays on startup nor TIME-WAIT periods on close.  
Each stream offers independent data transfer and flow control,  
allowing different transactions to proceed in parallel without head- 
of-line blocking, but all streams share one congestion control  
context. SST supports both reliable and best-effort delivery in a way  
that semantically unifies datagrams with streams and solves the  
classic “large datagram” problem, where a datagram's loss probability  
increases exponentially with fragment count. Finally, an application  
can prioritize its streams relative to each other and adjust  
priorities dynamically through out-of-band signaling. A user-space  
prototype shows that SST is TCP-friendly to within 2%, and performs  
comparably to a user-space TCP and to within 10% of kernel TCP on a  
WiFi network.

Lars

---

From: Fred Baker <[email-masked]>
Date: Mon, 17 Sep 2007 02:13:42 -0700

Dumb question of the month. With the exception of the last claim  
("...can prioritize..."), this could just as easily describe SCTP.  
What here is new? And define "prioritize"?

On Sep 17, 2007, at 2:02 AM, Lars Eggert wrote:
> instances. Structured Stream Transport (SST) enhances the  
> traditional stream abstraction with a hierarchical hereditary  
> structure, allowing applications to create lightweight child  
> streams from any existing stream. Unlike TCP streams, these  
> lightweight streams incur neither 3-way handshaking delays on  
> startup nor TIME-WAIT periods on close. Each stream offers  
> independent data transfer and flow control, allowing different  
> transactions to proceed in parallel without head-of-line blocking,  
> but all streams share one congestion control context. SST supports  
> both reliable and best-effort delivery in a way that semantically  
> unifies datagrams with streams and solves the classic “large  
> datagram” problem, where a datagram's loss probability increases  
> exponentially with fragment count. Finally, an application can  
> prioritize its streams relative to each other and adjust priorities  
> dynamically through out-of-band signaling. A user-space prototype  
> shows that SST is TCP-friendly to within 2%, and performs  
> Lars_______________________________________________
> Ietf mailing list
> [email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Mon, 17 Sep 2007 13:11:34 +0300

> What here is new? And define "prioritize"?

For how this relates to SCTP, let me refer you to Section 6. (And  
yes, there are obvious similarities here to SCTP, but also RFC2140- 
like integrated congestion control, etc.)

"Prioritize" meaning how a sender allocates the available path  
capacity for the SST "bundle" between connection instances. A demo  
that Bryan did that showed HTTP over SST dynamically adjusted  
priorities such that objects that were being rendered on the screen  
were transmitted at a higher priority, even while scrolling around a  
large page.

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 17 Sep 2007 12:57:12 +0200

Hi Lars,

comment in-line.

Best regards
Michael

On Sep 17, 2007, at 12:11 PM, Lars Eggert wrote:

> were transmitted at a higher priority, even while scrolling around  
> a large page.
The SCTP sender can handle multiple messages in different stream send  
queues in different ways.
I call the selection function the "stream scheduling function". Using  
different scheduling
functions at the sender side you can get different "fairness  
concepts". Message based
round robin would get the fairness concept of having the same number  
of messages in each
stream, doing a weighted fair queueing based scheduler you can share  
the bandwidth equally
between the different streams and so on. Priorities are also simple  
to implement and have
an analysed in
http://www.cis.udel.edu/~amer/PEL/poc/pdf/sci2004-heinz-SCTP- 
Prioritized-Multistreaming.pdf
The nice thing with the scheduling function is: it is a sender only  
thing. The receiver has
to follow some simple rules, which almost all SCTP implementation do  
anyway.
>>> You might be interested in Bryan Ford's SST paper from this  
>>> year's SIGCOMM:
>>>

---

From: John Day <[email-masked]>
Date: Mon, 17 Sep 2007 07:13:46 -0400

I am afraid that I must agree with Fred.  There is nothing very new 
in this paper and its publication is merely another indication of how 
far down the blind alley we have gone.  I was surprised SIGCOMM even 
published dressing up X.25 Fast Select with fancy words.  Amazing.

At 2:13 -0700 2007/09/17, Fred Baker wrote:
>>You might be interested in Bryan Ford's SST paper from this year's SIGCOMM:
>>
>>SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. 
>>http://www.brynosaurus.com/pub/net/sst-abs.html
>>
>>unifies datagrams with streams and solves the classic "large 
>>datagram" problem, where a datagram's loss probability increases

---

From: Scott Brim <[email-masked]>
Date: Fri, 14 Sep 2007 09:52:09 -0400

> > encourages protocol design to be directed by corner cases.

But corner cases do need to be considered.  If nothing else they
inform the design.  If there is a process failure, it's a failure to
correctly evaluate the significance of the corner cases considered.
Coming up with the corner cases is clever, but figuring out which ones
to take seriously is harder, as it requires accurately predicting
technological, cultural, political and economic futures.  We could use
some more capability there.

> talking about _all_ the pieces, not just the 80% that are the
> easiest and we know how to do.

Agree (but we're trying for the next 5%).

> On the other hand, if we don't know how to do a scalable mapping
> part yet, that sounds like research to me. (Insert long-running
> discussion here about how DNS is or is not good enough to provide
> this functionality.)

I prefer to keep things out of WGs until we know what it is we're
supposed to *engineer*, or at least until figuring that out won't take
long.

> think we know how to this and can make it work and just need to agree

It's a continuum.  RRG is full of people who consider themselves
engineers and who participate in the IETF as well.

swb

---

From: Scott Brim <[email-masked]>
Date: Fri, 14 Sep 2007 09:52:09 -0400

swb

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 17 Sep 2007 06:24:41 -0700

This is not an academic institution. We do not as the founder of my Oxford College put it, have to 'care more for novelty than for truth'.

What failed in 1980 may have failed because it was a bad idea or because it was a good idea whose time has not yet come. Or it may have failed for no other reason than a different choice was made.

> From: Fred Baker [mailto:[email-masked]] 
> Sent: Monday, September 17, 2007 5:14 AM
> To: Lars Eggert
> Cc: ext Tony Finch; Keith Moore; IETF-Discussion
> Subject: Re: session layers,was Re: Renumbering ... Should we 
> consider an association thatspans transports?
> 
> Dumb question of the month. With the exception of the last 
> claim ("...can prioritize..."), this could just as easily 
> describe SCTP.  
> > Abstract: Internet applications currently have a choice 
> between stream 
> > and datagram transport abstractions. Datagrams efficiently support 
> > small transactions and streams are suited for long-running 
> > applications like HTTP that exhibit a mixture of 
> transaction sizes, or 
> > applications like FTP and SIP that use multiple transport 
> instances. 
> > Structured Stream Transport (SST) enhances the traditional stream 
> > abstraction with a hierarchical hereditary structure, allowing 
> > stream. Unlike TCP streams, these lightweight streams incur neither 
> > 3-way handshaking delays on startup nor TIME-WAIT periods on close. 
> > allowing different transactions to proceed in parallel without 
> > head-of-line blocking, but all streams share one congestion control

---

From: Tony Finch <[email-masked]>
Date: Mon, 17 Sep 2007 15:07:28 +0100

On Mon, 17 Sep 2007, John Day wrote:

> I am afraid that I must agree with Fred.  There is nothing very new in this
> paper and its publication is merely another indication of how far down the
> blind alley we have gone.  I was surprised SIGCOMM even published dressing up
> X.25 Fast Select with fancy words.  Amazing.

Isn't Fast Select more like RFC 1644 TCP for Transactions than Ford's
Structured Streams? IIUC, X.25 and SCTP have similarly static multiplexing
configurations and delimited records, unlike SST.

Tony.

---

From: John Day <[email-masked]>
Date: Mon, 17 Sep 2007 10:40:26 -0400

Fast Select was a single packet that opened, transfered data, and 
closed a connection. The same as what Mr. Ford's description.  There 
was nothing remotely "transactional" about Fast Select.  It was a 
direct counter to the proposal to put datagrams in X.25.  It was a 
silly idea, then and it remains so.  Deeper thinking about the nature 
of the problem would have yielded simpler results than SST.

I do admit to taking a cheap shot at one of the more obvious 
weirdnesses in an amazingly weird paper as SIGCOMM continues to 
promulgate the groupthink, rather than break it.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 18 Sep 2007 10:22:42 +0300

On 2007-9-17, at 17:40, ext John Day wrote:
> closed a connection. The same as what Mr. Ford's description.

What you outline above is very different from SST. I'm surprised that  
after reading the paper you'd think that there are strong similarities.

Lars

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 18 Sep 2007 08:02:19 -0700

> you can argue it shouldn't be this way, but reality often sucks.

I am not looking for a never-ending debate either. What people are
overlooking is that part of any viable transition plan is to allow people to
deploy the new widget in a way that they understand and are comfortable
with. The fact that people -can- deploy IPv6 the same way they deploy IPv4
is a feature, not a requirement that they actually deploy it that way.
Statements like yours only confuse people because they take it literally
rather than in context that current deployments are not looking at the
protocol differences beyond 'more bits'. When people start from the
perspective that 'the names both start with IP and they are both packet
delivery systems but they are different protocols' then find the
similarities, they are much better off than when they start from the 'just
more bits' perspective. 

> to make use of the new bits.

Either you need backwards compatibility, or you need the ability to support
both until the old systems die off naturally. There was plenty of time to
support both for a graceful transition, but people seem to want to wait
until they are forced to change before they start, so the actual shift will
be ugly and costly.

> system (that doesn't require manual intervention) that supports this?

The applications you are looking for can't exist or be economically
supported in IPv4/nat, so they have yet to make it to the market place. That
does not mean 'we must restrict IPv6 deployments to match IPv4', even if the
initial deployments are happening that way. There is a strong tendency to
only worry about supporting current applications, but we really need to be
building a framework to allow new applications to appear that failed
economically in the past. While IPv4 is a good protocol, the general
attitude that 'if it can't be done with IPv4 it is not worth doing' needs to
go away. 

Tony

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Sep 2007 09:45:52 -0700

Tony Hain wrote:
>      The fact that people -can- deploy IPv6 the same way they deploy IPv4
> protocol differences beyond 'more bits'. 

Are there any documents that give adoption instructions for what are expected 
to be common scenarios?  These would be step-by-step cookbooks, with 
explanations for when they apply and when they don't?

We often create capabilities that are both easy to start using and quite 
flexibile in the considerable range of what they permit.  Focus on the latter 
and things look too complicated.  Focus only on the former and things look too 
limited.

Easy to start using is great for initial adoption and immediate benefit.

Given the adoption hurdles IPv6 has been showing, then efforts to both make it 
easy and publicize/document that it's easy could be helpful.

d/

-- 

   Dave Crocker

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 18 Sep 2007 16:26:15 -0500

Thus spake "Noel Chiappa" <[email-masked]>
> PI, the ISP's say no. Got it.

The ISPs fought it, but in the end they've accepted PI because the 
enterprises are the ones paying their bills.  If supporting PI raises their 
costs, it'll raise _everyone's_ costs and the enterprises will continue to 
pay.

> Just out of curiousity, how do the enterprises expect to exhange bits 

Lots of business associations _do_ operate private networks -- not connected 
to the public Internet or any ISP -- to exchange bits with each other 
reliably.  Those folks generally do not participate in the IETF/RIR process, 
so many forget they exist.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: <[email-masked]>
Date: Wed, 19 Sep 2007 08:34:52 +0100

> Are there any documents that give adoption instructions for 
> what are expected to be common scenarios?  These would be 
> step-by-step cookbooks, with explanations for when they apply 
> and when they don't?

There are lots and lots of documents in lots and lots of places. Many of
them were written years ago and include deprecated stuff, such as 6bone.
They are written from numerous points of view, i.e. enterprise, academic
campus, Research & Education Network, European, etc.

> Given the adoption hurdles IPv6 has been showing, then 
> efforts to both make it easy and publicize/document that it's 
> easy could be helpful.

Yes. Given that the IPv4 exhaustion date is now within the planning
horizon of ISPs, ARIN has set up a wiki at http://www.getipv6.info to
document how to use IPv6. Since ARIN's audience is ISPs, this is taking
the ISP point of view to the problem.

For instance, if you are an end user, 6to4 is something that you
configure to dip your toes in IPV6 and see how it works without touching
existing IPv4 infrastructure. But for an ISP, 6to4 is a relay service
that you configure in several routers to ensure that an end user's early
experience with IPv6 is more positive and less likely to include high
hop count, and high latency caused by trombone-shaped tunneling
architecture.

IMHO the type of document that Dave is talking about requires many
authors. A wiki is well-suited to creating such documents. But it needs
contributors who know something about IPv6 who will write up some of
this cookbook material, or dust off old papers and presentations and
copy the key bits, with corrections, into the wiki.

--Michael Dillon

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 19 Sep 2007 10:11:15 -0500

Thus spake "Spencer Dawkins" <[email-masked]>
> My apologies for intruding, because I haven't been following the
> technology during the past couple of years, but V6OPS did an
> informational RFC on renumbering without a flag day
> (http://www.ietf.org/rfc/rfc4192.txt) in 2005.
>

It's helpful in that it documents how to solve maybe a quarter to a half of 
the technology problems with renumbering.  It doesn't solve a lot of other 
ones, including _any_ of the human problems.

The human problems are easily 90% of the effort involved in renumbering. 
That many of those problems are self-imposed is irrelevant, since they are 
political problems, not technical problems, and thus outside the scope of 
the IETF's work.  Perhaps better tools would make it easier to solve those 
political problems, but telling people that change control processes or 
security rules are "wrong" is just going to get you ignored.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 19 Sep 2007 10:48:22 -0500

Thus spake "Iljitsch van Beijnum" <[email-masked]>
>>>> How do you renumber the IP address stored in the struct  sockaddr_in in 
>>>> a long running critical application?
>

Many proprietary protocols do not have the ability to checkpoint a 
connection and resume it on a different socket.  It is not uncommon to 
require human intervention to retry a connection, or to have to redo all the 
work from scratch.  It is also not uncommon for server applications to crash 
if their IP address is changed out from under them, or refuse to load with a 
new IP address.

> Since when is it the job of applications to manage DNS TTLs?

It's not.  However, many applications are coded to ask DNS once for each 
name and cache the result forever; this is a problem for long-lived 
processes, particularly servers, though it can even be seen in common web 
browsers.  Some OSes include a caching resolver that has similar bugs.  Some 
ISPs have caching nameservers that increase TTLs.

All of those things are broken, of course.  That doesn't change the fact 
they exist and folks in the operational community will not be impressed with 
a "solution" that ignores those problems.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 19 Sep 2007 10:48:22 -0500

S

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 Sep 2007 18:33:13 +0200

On 19-sep-2007, at 17:48, Stephen Sprunk wrote:

> All of those things are broken, of course.  That doesn't change the  
> fact they exist and folks in the operational community will not be  
> impressed with a "solution" that ignores those problems.

Sometimes ignoring a problem really does make it go away. Install a  
workaround, on the other hand, and the brokenness remains non-obvious  
so it persists.

I'm not advocating going around and breaking implementations that  
don't fully conform with specs on purpose, but if doing the right  
thing means that out-of-spec implementations see some problems, I can  
usually live with that.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 20 Sep 2007 14:19:57 -0500

>> they exist and folks in the operational community will not be  impressed 
>> with a "solution" that ignores those problems.
>
> Sometimes ignoring a problem really does make it go away.
> Install a workaround, on the other hand, and the brokenness
> remains non-obvious so it persists.

If often persists whether it remains non-obvious or not.  I can't count how 
many hotels I've visited where I have to disable v6 on my laptop for v4 DNS 
to work because their boxes break horribly when confronted with an AAAA 
lookup.  This has been going on for _years_ and the operators and vendors 
obviously don't care even though the problem is blatantly obvious.

> I'm not advocating going around and breaking implementations
> that don't fully conform with specs on purpose, but if doing the
> right thing means that out-of-spec implementations see some
> problems, I can usually live with that.

Whether I can live with that in a particular case depends on what percentage 
of the userbase will see "some problems" if that brokenness is exposed.

For instace, we accomodate multi-faced DNS because most "major" web sites 
would become inaccessible if it weren't.  If you are proposing a new 
protocol that would not accomodate it, forcing users to choose between that 
protocol and being able to access Google, Yahoo, CNN, MySpace, etc., it's 
obvious which the masses will choose.

S

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 21 Sep 2007 11:54:18 +0200

> If often persists whether it remains non-obvious or not.  I can't  
> count how many hotels I've visited where I have to disable v6 on my  
> laptop for v4 DNS to work

Yes, hotels are the worst. In Chicago two months ago they used a NAT  
timeout in my hotel that was so short that my SSH, IMAP and IM  
sessions timed out every few minutes.

> because their boxes break horribly when confronted with an AAAA  
> lookup.  This has been going on for _years_ and the operators and  
> vendors obviously don't care even though the problem is blatantly  
> obvious.

Obviously this should be fixed. But: you may ask yourself: why is  
your system doing AAAA lookups when you obviously don't have IPv6  
connectivity?

> Whether I can live with that in a particular case depends on what  
> percentage of the userbase will see "some problems" if that  
> brokenness is exposed.

Ah yes, the "if enough people do something wrong it becomes right"  
doctrine. So here in Holland we have "alcohol free" beer that  
contains 0.5% alcohol, and megabytes are now 1000000 bytes.

> For instace, we accomodate multi-faced DNS because most "major" web  
> sites would become inaccessible if it weren't.

??? How come?

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 21 Sep 2007 13:33:20 -0500

>> If often persists whether it remains non-obvious or not.  I can't  count 
>> how many hotels I've visited where I have to disable v6
>> on my laptop for v4 DNS to work
>
> Yes, hotels are the worst. In Chicago two months ago they used
> a NAT timeout in my hotel that was so short that my SSH, IMAP
> and IM sessions timed out every few minutes.

Same problem with most WiFi hotspots; I think they use the same all-in-one 
boxes for HTTP-interception, DNS, DHCP, etc.  There are few vendors in that 
space whose boxes _aren't_ broken in myriad different ways.  Operators don't 
care because they've already gotten your money by the time you discover the 
brokenness.

>> because their boxes break horribly when confronted with an
>> AAAA lookup.  This has been going on for _years_ and the
>> operators and vendors obviously don't care even though the
>> problem is blatantly obvious.
>
> Obviously this should be fixed.  But: you may ask yourself: why
> is your system doing AAAA lookups when you obviously don't
> have IPv6 connectivity?

Anyone from Microsoft listening?

I suppose, in theory, a DNS query over v4 might return an AAAA record that 
_is_ accessible via one of my link-local addresses or the loopback address. 
As long as v6 is _enabled_ on a Windows box, it does AAAA queries, even if 
it has to send them via v4.  I'm told WinXP isn't even capable of doing DNS 
over v6.

>> percentage of the userbase will see "some problems" if that  brokenness 
>> is exposed.
>
> Ah yes, the "if enough people do something wrong it becomes
> right" doctrine. So here in Holland we have "alcohol free" beer
> that contains 0.5% alcohol, and megabytes are now 1000000
> bytes.

That complaint doesn't resonate so well when you're writing in a language 
whose "rules" are defined by whatever people do and if enough people do 
something "wrong" it gets reclassified as "right".

There's a difference between de jure and de facto standards.  That's not to 
say that de jure standards are not needed -- they obviously are -- but when 
the majority of people are ignoring them, you can't just stick your head in 
the sand and ignore the de facto reality.  That _should_ be a sign that the 
de jure standards need rewriting after one reviews _why_ the de facto 
standard has diverged.

S

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 22 Sep 2007 18:49:46 +0200

> I suppose, in theory, a DNS query over v4 might return an AAAA  
> record that _is_ accessible via one of my link-local addresses or  
> the loopback address.

Yeah right. Try again.

> As long as v6 is _enabled_ on a Windows box, it does AAAA queries,  
> even if it has to send them via v4.

Looks like you're right, and it also seems to be a system-wide thing,  
because Safari on Windows also first generates a query for a AAAA  
record and then for a A record on XP with IPv6 enabled but with no  
local IPv6 router and a private address = no 6to4.

On the Mac it's A first and then AAAA but only when there's actual  
IPv6 connectivity. This won't trigger AAAA related bugs too badly  
even when IPv6 is enabled.

>   I'm told WinXP isn't even capable of doing DNS over v6.

You can't set up an IPv6 address for a DNS resolver, no.

> That complaint doesn't resonate so well when you're writing in a  
> language whose "rules" are defined by whatever people do and if  
> enough people do something "wrong" it gets reclassified as "right".

I don't think these redefinitions can be classified as a language issue.

I'll be happy to repeat my statements in a language that has a  
committee that gets to decide what's officially correct in the  
language, but I don't think that helps for a variety of reasons, one  
being that the committees don't get it right much of the time either.

> There's a difference between de jure and de facto standards.   
> That's not to say that de jure standards are not needed -- they  
> obviously are -- but when the majority of people are ignoring them,  
> you can't just stick your head in the sand and ignore the de facto  
> reality.  That _should_ be a sign that the de jure standards need  
> rewriting after one reviews _why_ the de facto standard has diverged.

Within the context of what we're doing in the IETF, that's extremely  
simple: programmers are lazy. And if they're not lazy themselves,  
their bosses don't give them enough time to do non-lazy work. I know  
a programmer who is held in very high regard who will write two extra  
pages of code just to do bounds checking for possible a buffer  
overflow that can't even happen in the first place, but he never  
checks for overflow conditions. If he'd written a TCP implementation,  
sessions would break after transmitting (at most) 4 GB of data  
because after 4294967295 the TCP sequence number becomes 0 again but  
his code doesn't check for this transition.

Why bother with details like that if you can simply make the field  
bigger and let the support people clean up the mess a few years down  
the road when you run out of the extra bits? Which brings us back to  
the topic of the discussion: why do things the hard way if it's so  
easy to put an IP address in a configuration file?

---

From: Mark Andrews <[email-masked]>
Date: Mon, 24 Sep 2007 10:07:28 +1000

> >> is your system doing AAAA lookups when you obviously don't

	Almost all boxes these days have internal IPv6 connectivity.
 
> > record that _is_ accessible via one of my link-local addresses or  

	Don't you have "localhost AAAA ::1" and "localhost A
	127.0.0.1" configured in you DNS?

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 Sep 2007 22:16:26 -0400

> Obviously this should be fixed. But: you may ask yourself: why is your
> system doing AAAA lookups when you obviously don't have IPv6
> connectivity?
Because the application asked it to do them?

Here's the thing.  I don't want getnameinfo() or any other API that does
DNS lookup to act differently depending on whether the system seems to
have external IPv6 connectivity or not (unless the app explicitly asked
for this), because my app might have a valid reason for wanting to know
if there's an AAAA record associated with a name even if the system
doesn't have external IPv6 connectivity.  For instance, my app might
have an RSIP or socks or explicitly controlled NAT service available
that can let it access the IPv6 network, or it might be providing
referrals to peers that can make use of an IPv6 address.

More generally, I don't want anything that handles DNS queries - be it
the API or a cache server or any intermediary or really even an
authoritative server, to be trying to make guesses about how to
interpret a query based on anything other than the information in that
query - class, query RR type, name, etc.   The view of DNS needs to be
consistent from one host to another and one query to another if we want
applications to work reliably.   Over-clever APIs, NATs with DNS ALG,
other intermediaries that try to guess what the app wants or needs are
not doing a service to anybody.  They're just making the DNS less
predictable, less consistent, and less usable by apps. (as for
multi-faced DNS, it is is a mixed blessing at best)

As for intermediaries that try to intercept DNS queries and screw with
the query or the results:  In general, the problem with intermediaries
is that they need to be smarter than both endpoints.   Intermediaries
essentially always fail at this.  One reason is that endpoints are so
diverse in their implementations and needs.  Another reason is that
intermediaries tend to be invisible  (not "transparent" which is
something different).  So when things break, attention is focused on the
endpoints even though the intermediary is responsible for the breakage.

But the last thing you need is an API that tries to second guess what
the intermediary is doing and work around bugs in the intermediary. 
Because that just makes the system as a whole even less predictable, and
makes it take longer to get the broken intermediaries fixed. 

Keith

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 24 Sep 2007 10:44:20 +0200

On Sun, Sep 23, 2007 at 10:16:26PM -0400,
 Keith Moore <[email-masked]> wrote 
 a message of 53 lines which said:

> I don't want getnameinfo() or any other API that does DNS lookup to
> act differently depending on whether the system seems to have
> external IPv6 connectivity or not (unless the app explicitly asked
> for this),

getaddrinfo() or getnameinfo() are *not* supposed to do DNS lookups,
they are supposed to do name-to-address mapping, using whatever system
they were configured for (may be the DNS, may be LDAP, may be
/etc/hosts).

> because my app might have a valid reason for wanting to know if
> there's an AAAA record associated with a name even if the system
> doesn't have external IPv6 connectivity.

OK, then it requires a low-level system call, doing only DNS lookups
(this API already exists, BTW). getaddrinfo() is for applications who
want the high-level view.

> More generally, I don't want anything that handles DNS queries - 

Then, getaddrinfo() is out of scope, since it was never conceived as a
DNS debugging tool.

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Sep 2007 06:43:57 -0400

> they were configured for (may be the DNS, may be LDAP, may be
yeah, I know.  and that's *broken*.  because if people want apps to use
DNS names, then apps need a consistent way to do DNS name lookups from
one app to another.  why shouldn't the standard name lookup API do this?
> want the high-level view.
there's no standard API to do this.  and there needs to be.
> DNS debugging tool
who said anything about debugging?    there are a  number of apps that
are required, as a matter of standards conformance, to do DNS queries if
they want to operate correctly.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Sep 2007 15:18:03 +0200

On 24-sep-2007, at 4:16, Keith Moore wrote:

>> your

> Because the application asked it to do them?

Did it?

If you look up the getaddrinfo() man page (see top Google hits for a  
link to the implementation in your favorite OS) you'll see that it's  
possible to specify a protocol family or "accept any protocol family  
supported by the operating system".

(But: protocol family? Didn't we call these things address families?)

In my opinion, when the application says "unspecified", it's entirely  
reasonable for the OS to only supply addresses of a type that  
currently has reachability.

> doesn't have external IPv6 connectivity.

I agree that if an application specifically asks for something the OS  
etc shouldn't pretend it doesn't exist if it does, but I disagree  
that there are significant valid cases where this is required.

> The view of DNS needs to be
> applications to work reliably.

Sure. (Hence the evilness of two-faced DNS. Yes, flame away.)  
However, that doesn't apply here: there is no requirement that if  
someone asks for one record type, she is informed of all other record  
types as well.

Following your logic, the Windows logic of always asking for AAAA  
records when IPv6 is enabled doesn't go far enough: it should ask for  
AAAA records even when IPv6 is disabled administratively. And MX  
records, TXT records...

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Sep 2007 15:20:38 +0200

> 	127.0.0.1" configured in you DNS?

You got me there.  :-)

I don't think that specific case warrants asking for AAAA records all  
the time for everything even though there is no IPv6 connectivity,  
though. The proper way to do this is probably to make localhost a  
special case in the resolver library. This also helps avoiding  
weirdness when some joker puts "localhost" with a non-localhost  
address in one of your search domains.

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Sep 2007 10:01:10 -0400

> currently has reachability.
Well, I'm not sure what the specification means by this.  But that's
kind of a separate issue.  The point is that the application might well
have a need for AAAA records and to request AAAA records in a DNS lookup
even if the local host doesn't have external IPv6 connectivity - or
perhaps no IPv6 connectivity at all.  You don't want API second-guessing
this stuff.
> etc shouldn't pretend it doesn't exist if it does, but I disagree that
> there are significant valid cases where this is required.
Whenever I look at what it takes to make IPv6 transition viable, I find
cases where it is essential to be able to host a IPv4 service on an
IPv6-only network and vice versa.  So I disagree.
> Sure. (Hence the evilness of two-faced DNS. Yes, flame away.) However,
> that doesn't apply here: there is no requirement that if someone asks
> for one record type, she is informed of all other record types as well.
Provided that they get what they ask for.
> AAAA records even when IPv6 is disabled administratively. 
If the app requests them, yes.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Sep 2007 08:34:00 +1000

> address in one of your search domains.

	Actually getaddrinfo() not asking for AAAA all the time is
	broken if you add in searching which most/all getaddrinfo()
	calls do.

	You want to get to the *same* name when searching regardless
	of whether it has A, AAAA or AAAA & A records.  There are two
	way to achieve this.

	1. you stop when you get a NODATA response.
	2. you stop when there is a A or AAAA record at the name.
 
	The IETF/POSIX needs to specify what is the correct algorithm
	to use when searching.  Note the first cannot be applies to
	anyother backend than the DNS.

		getaddrinfo("foo") and getaddrinfo("ftp.uu.net")

	        search "example.org example.net example.com"

		foo.example.org A 1.2.3.4
		foo.example.net A 2001::1
		*.example.com A 1.2.3.5
		*.example.com A 2001::2

		What is the correct response on a
		* IPv4 only machine
		* IPv6 only machine
		* dual stack machine

		Note ftp.uu.net does NOT have AAAA records

	Mark

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Sep 2007 00:45:07 +0200

> 	of whether it has A, AAAA or AAAA & A records.  There are two

I don't understand what you're saying: "get the same name"? We're  
talking about getting addresses, we already have the name.

> 	        search "example.org example.net example.com"

You really don't want to have a list of search domains, the ambiguity  
will bite you at some point. Better to stick with fully qualified names.

> 		foo.example.net A 2001::1

(Don't you mean AAAA for the IPv6 addresses?)

You are comingling way too many things here. Let me simply conclude  
that foo.example.org is the first name that is tried and since it  
exists what comes back for that name is what's going to be used. I'm  
reasonably sure this is even the case when "what comes back" is an  
empty set.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Sep 2007 10:18:27 +1000

Yes.
 
> exists what comes back for that name is what's going to be used.

	Actually it isn't specified what should happen.

	If you don't make AAAA queries most(all?) existing search
	algorithms will continue to foo.example.net.  Remember, in
	the DNS, a name can exist yet have not records associated
	with it (rcode=NOERROR ancount=0 is returned for all types).

	Similarly if you don't make A queries you will end up with
	ftp.uu.net.example.com.

	RFC 3493 says:

      For example, when using the DNS, a query for AAAA records should
      occur only if the node has at least one IPv6 address configured
      (other than IPv6 loopback) and a query for A records should occur
      only if the node has at least one IPv4 address configured (other
      than the IPv4 loopback).

	This is actually dangerous when searching is done.

> I'm  

	And in the deployed code this co-mingling occurs.  It's reality
	and we, the IETF, should define what it the best/safest/correct
	behaviour when that occurs.

	People like to use unqualified *and* partially qualified hostnames.
	We should be writting specifications that take this into account.
	We have not done that for getaddrinfo().

	Mark

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Sep 2007 10:09:23 -0400

> 	of whether it has A, AAAA or AAAA & A records. 

+1

and furthermore the result needs to be the same regardless of whether
this is done on an IPv4-only, IPv6-only, or dual-stack and
dual-connected machine.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Sep 2007 08:55:34 +1000

> this is done on an IPv4-only, IPv6-only, or dual-stack and

	In otherwords it need to be independent of the setting of
	AI_ADDRCONFIG.

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Sep 2007 19:43:37 -0400

> 	In otherwords it need to be independent of the setting of
Well, that's not saying quite the same thing that I was trying to say.

The /name/ on which the query is based should be independent of whether
AI_ADDRCONFIG is set.  However the /result/ of the query can still
differ based on whether that flag is set.  And if AI_ADDRCONFIG is not
set, the result of the query should be the same regardless of whether
the host has IPv4 access, IPv6 access, or both.  This implies that the
query is being done on the same name in both cases.

(Actually I think that AI_ADDRCONFIG is so ambiguously defined as to be
fairly useless in practice.  But I also think that searching through
multiple zones is a bad idea.)

Keith

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Sep 2007 10:46:04 +1000

> query is being done on the same name in both cases.

	It also means that you need to stop searching if there is
	a A or AAAA record regardless of which address families are
	configured.  This notion that a IPv4 only box doesn't need
	to make AAAA queries is completely bogus.

	Mark

	P.S.
	I think hotels will quickly fix the AAAA brokenness now
	that Vista is shipped.  This won't fix all the DNS breakage
	they cause but that part will go away.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Sep 2007 15:07:10 +0200

> 	with it (rcode=NOERROR ancount=0 is returned for all types).

Looks like you're right, at least as far as my Mac is concerned.

I set up two subdomains test1 and test2 with each the hosts a, b, c  
and d with the following addresses:

           IPv6   IPv4
a.test1     X      X
b.test1     X      -
c.test1     -      X
d.test1     -      -
a.test2     -      -
b.test2     -      X
c.test2     X      -
d.test2     X      X

Then I set up test1.runningipv6.net, test2.runningipv6.net up as my  
search domains. (Info is still in there, feel free to try for  
yourself. TTL is 20 seconds.) Results on my Mac running the latest  
updates with both IPv4 and IPv6 connectivity:

(host talks directly to the DNS and looks for both A and AAAA)

$ host a
a.test1.runningipv6.net has address 192.0.2.101
a.test1.runningipv6.net has IPv6 address 2001:db8:1::a
$ host b
b.test1.runningipv6.net has IPv6 address 2001:db8:1::b
$ host c
c.test1.runningipv6.net has address 192.0.2.103
$ host d
d.test2.runningipv6.net has address 192.0.2.204
d.test2.runningipv6.net has IPv6 address 2001:db8:2::d

(traceroute only does IPv4)

$ traceroute a
traceroute to a.test1.runningipv6.net (192.0.2.101), 64 hops max, 40  
byte packets
$ traceroute b
traceroute to b.test2.runningipv6.net (192.0.2.202), 64 hops max, 40  
byte packets
$ traceroute c
traceroute to c.test1.runningipv6.net (192.0.2.103), 64 hops max, 40  
byte packets
$ traceroute d
traceroute to d.test2.runningipv6.net (192.0.2.204), 64 hops max, 40  
byte packets

(traceroute6 only does IPv6)

$ traceroute6 a
traceroute6 to a.test1.runningipv6.net (2001:db8:1::a) from
$ traceroute6 b
traceroute6 to b.test1.runningipv6.net (2001:db8:1::b) from
$ traceroute6 c
traceroute6 to c.test2.runningipv6.net (2001:db8:2::c) from
$ traceroute6 d
traceroute6 to d.test2.runningipv6.net (2001:db8:2::d) from

(telnet does both IPv4 and IPv6)

$ telnet a
Trying 2001:db8:1::a...
$ telnet b
Trying 2001:db8:1::b...
$ telnet c
Trying 2001:db8:2::c...
$ telnet d
Trying 2001:db8:2::d...

So your issue that the results are inconsistent is certainly real.

I'd say that the best way to avoid this is not having a search domain  
at all, or at the very least not several. If someone wants to spend  
time to come up with a reasonable guideline of how to behave that  
gives the same results regardless of the type of connectivity that's  
available, that would be good but probably extremely hard to do.

> 	People like to use unqualified *and* partially qualified hostnames.

People also like to drive without seat belts. We don't let them do  
that either... Or at least, we don't listen to their complaints when  
the results are inferior to those obtained while driving _with_ a  
seatbelt.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Sep 2007 11:33:56 +1000

> at all, or at the very least not several.

	Which is a totally unreasonable suggestion.

	The problem here is not the search but different stoping
	critera depending apon the address families supported by
	the host or requested by the application.

	We wrote a API that failed to account for the usual use
	senario.  In fact the guidance in there is the direct
	opposite of what should be done with the usual use senario.

	It perfectly fine for a MTA which get fully qualified names
	in MX records then looks up the addresses.  MTA's should
	be disabling name searching in the resolver.  That however
	is not how most application work nor how the users of those
	applications want them to work. They want to be able to
	search.  I've actually had requests to extend the number
	if domains that can be in the search list.

> If someone wants to spend  

> the results are inferior to those obtained while driving _with_ a  

	We also put air bags in cars to help those that don't use
	saftey belts.

	I'm saying we should go back and fix the specification for
	getaddrinfo() so that it accounts for searching.  Make the
	optimisation of not looking for A/AAAA record only occur
	when searching is disabled.  Make the queries for both types
	manditory when searching.

	This will cause getaddinfo() to return consistant results.

	We should also add a AI_NOSEARCH flag so that searching is
	controlled directly rather than indirectly.  The lack of a
	AI_NOSEARCH define would mean the application would use the
	indirect method.
 
	Mark

	I've set Reply-To to [email-masked] as this is more approriate
	for 6man.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Sep 2007 17:42:38 +0200

> 	Which is a totally unreasonable suggestion.

It's not. Even without IPv6, having search domains means you can get  
unexpected results. If that's not acceptable, don't complain, but put  
a period behind your FQDNs.

> 	opposite of what should be done with the usual use senario.

I thought the solution would be hard or would be suboptimal in the  
common case, but I think that doesn't have to be so.

In my example, MacOS would go through the search domains and keep  
going until it found AAAA records for IPv6 or IPv4+IPv6 applications  
(and presumably look for A records if there were no AAAA records and  
IPv4 was present/requested also).

So basically, both the "answers = 0, noerror" and "nxdomain"  
responses trigger trying the next search domain. If we change this to  
"answers = 0, noerror" means try the same FQDN again for an A record,  
and "nxdomain" means move on to the next search domain, the results  
for different permutations of IP version availability would all  
result in connecting to the same FQDN = the first one with an address  
that's compatible with current connectivity, rather than the first  
one with an AAAA record if there is IPv6 connectivity.

> 	getaddrinfo() so that it accounts for searching.

Volunteers...?

> 	controlled directly rather than indirectly.

That's what the period terminating a domain name is for.

> 	I've set Reply-To to [email-masked] as this is more approriate

No, it's a DNS issue, so it should go to dnsop. dnsop people: see  
discussion between Mark, Keith and me that started under the subject  
"renumbering" on the ietf discussion list.

Everyone: feel free to prune some lists when you respond.  :-)

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Sep 2007 12:44:01 -0400

> 	the host or requested by the application.
Well, let's be fair.  Search creates lots of problems other than this
one.   Right now there's not really any way to unambiguously specify a
FQDN that works across all applications, has the same meaning across all
applications, and has the same meaning independent of what host the
query is being made from.  That's a real problem.

Yes, users like search, but it's arguably a Bad Idea, particularly in
the absence of a universal syntax that says "don't subject this name to
search".

IMHO the stopping criterion should be that if there are _any_ RRs
matching the name in a particular zone, the search should terminate.
> 	opposite of what should be done with the usual use senario.
The "usual use scenario" is broken, and it's based on a previous
poorly-designed API.
> 	if domains that can be in the search list.
I think you're grossly overgeneralizing here.  Email is far from the
only application that needs for DNS names to be unambiguous.  And users
would benefit from having DNS names being used consistently from one app
to another, even though they may not realize this.
> 	We also put air bags in cars to help those that don't use
Maybe the equivalent of air bags in the case of DNS lookups would be
having an API that refused to search any name containing a ".".

Keith

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Sep 2007 09:48:38 +1000

> a period behind your FQDNs.

	Please state were in RFC 952 a final period is legal in
	a hostname. 

	Remember applications take HOSTNAMES not DOMAIN NAMES.
	There are HOSTNAMES that you cannot store in the DNS.
	There are DOMAIN NAMES that are not legal HOSTNAMES.

> > 	getaddrinfo() so that it accounts for searching.

	If need be, yes.
 
> That's what the period terminating a domain name is for.

	Again you confuse domain names and hostname.
 
> "renumbering" on the ietf discussion list.

	I chose [email-masked] (or it predecessor) because [email-masked]
	was where getaddrinfo()s behaviour was spec'd out.  We need to
	at least give the 6man a chance to address it.
 
	Mark

> DNSOP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Sep 2007 10:14:55 +1000

> matching the name in a particular zone, the search should terminate.

We need a new DNS rcode or universal deployment of DNSSEC to support
that in the DNS or make ANY queries on NODATA.  A NODATA response does
*not* indicate some rdata.

Stoping on NODATA might be feasible but you need to look at all the
possible backends.

> to another, even though they may not realize this.

	MTA's get FQHN from MX records.  They don't need to search.
	It's the MUA's job to qualify mail domains.  The MTA should
	be being given FQMD's.

	I'm sure there are other applications that only take fully
	qualified names, however most applications take unqalified
	names.

> having an API that refused to search any name containing a ".".

	I can hear the screams now.  However it would make the
	implementations simpler.  I don't think any vendor will
	stop supporting partially qualified names without a RFC
	prohibiting it.

	Mark

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Sep 2007 11:06:17 -0400

--On Friday, 28 September, 2007 09:48 +1000 Mark Andrews
<[email-masked]> wrote:

>...
>> It's not. Even without IPv6, having search domains means you
>> can get   unexpected results. If that's not acceptable, don't
>> complain, but put   a period behind your FQDNs.
> 

Mark, your recollection and understanding of history and
vocabulary may be different from mine (and probably is), but I
think you are getting confused by some informal terminology and
risking confusing others even further.

RFC 952 in fact prohibits trailing periods in domain names used
as host names, but 952 is a very early document, superceded by
all sorts of things both formally and informally.  I note, for
example, that it has been a rather long time since every
boundary router on the network (a "gateway") had a name ending
in "-GW" or "-GATEWAY".  Please don't read sentences of 952 out
of context and consider them binding.

You will not find the "hostname" versus "domain" distinction
made in RFC 1034.   1034 and its conceptual predecessors
discusses the domain name system as a replacement for the
hostname one and even notes (correctly) that different
applications have different syntax rules for names for hosts.
To make the ambiguity worse, when the term "host" or "hostname"
is used in applications in conjunction with the DNS, that term
often refers to the leaf-note label and not to the FQDN.  See,
for example, section 3.7 of RFC 821, which describes
"Fred.Cambridge.UK" as a possible "host-and-domain identifier".
However, the familiar "mailbox" is defined as
     <mailbox> ::= <local-part> "@" <domain>
Note that it is not 
          <local-part> "@" <hostname>
or
          <local-part> "@" <host-and-domain>

RFC 1034 also seems to believe that all fully-qualified (aka
"absolute") domains names, including those used to refer to
hosts, end in a period, even if that period is typographically
omitted for convenience.  Of course, it also contains a
masterwork of apparently-circular definition: "A domain is
identified by a domain name, and consists of that part of the
domain name space that is at or below the domain name which
specifies the domain."

While 1034 suggests that the trailing period is always
permitted, even if it is implied, Section 2.3.1 of 1035 gives a
syntax that doesn't permit them.   But it does so without trying
to distinguish between a "host" and a "domain".   In particular,
it says that [all of] "The labels must follow the rules for
ARPANET host names", which is ultimately a reference to 952
although 1035 repeats the rule.  That rule is applied to all
labels, not just the leaf one or ones identifying hosts.

As an indirect illustration of this, note that 1035 Section 3.5
describes IN-ADDR.ARPA as supporting "host address to host name
mapping".  That mapping is to an FQDN, not a label or "hostname"
as you use the term above.

RFC 1123 makes explicit provision for trailing dots in
application interfaces to domain names ("hosts") while noting
that RFC 822 (and 821) do not permit that syntax in the
protocols.  Nothing has ever permitted a UI designer, even for a
mail-related program, from accepting the trailing dot as long as
it is removed (and any searching or aliases resolved) before the
name goes out on the wire.

So I believe the distinction you are trying to make is not
historically supported, not particularly helpful, ambiguous, and
probably just plain wrong.

regards,
    john

---

From: Mark Andrews <[email-masked]>
Date: Sat, 29 Sep 2007 10:54:51 +1000

> made in RFC 1034.

	Actually will find the distinction made.
	Please go re-read RFC 1034 and RFC 1035.

	Mark

3.5. Preferred name syntax

The DNS specifications attempt to be as general as possible in the rules
for constructing domain names.  The idea is that the name of any
existing object can be expressed as a domain name with minimal changes.
However, when assigning a domain name for an object, the prudent user
will select a name which satisfies both the rules of the domain system
and any existing rules for the object, whether these rules are published
or implied by existing programs.

For example, when naming a mail domain, the user should satisfy both the
rules of this memo and those in RFC-822.  When creating a new host name,
the old rules for HOSTS.TXT should be followed.  This avoids problems
when old software is converted to use domain names.
	
	Note: NS specifies a HOST.

3.3.11. NS RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   NSDNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

NSDNAME         A <domain-name> which specifies a host which should be
                authoritative for the specified class and domain.

	Note: CNAME is a general DOMAIN.

3.3.1. CNAME RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                     CNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

CNAME           A <domain-name> which specifies the canonical or primary
                name for the owner.  The owner name is an alias.

>   1034 and its conceptual predecessors
> omitted for convenience.

> Of course, it also contains a

	It does for almost all possible hostnames.  Maximum length
	hostnames can't fit into the DNS.  For that mapping to be
	valid the data encoded in the FQDN must map back to a valid
	hostname.

	If I put "!@#@#$%%^&^&*$%^.example.net" in that
	PTR record would you claim that it is a valid hostname?

	The DNS is much more than a distributed HOST <-> ADDRESS
	mapping mechinism.  It was designed to be general.  This
	was a good thing.  However that does mean that you need to
	be aware of what is valid and what is invalid as the DNS
	itself does protect you when you get it wrong.

> name goes out on the wire.

	But forcing people to put the period in when we have stuffed
	up the API is just stupid.  RFC 1535 also shows that RFC 1123
	was wrong in this respect.  An absolute name should always
	match without having to remember to put periods at the end.
	The common search strategy didn't do this along with
	automatically created search lists lead to the *.EDU.COM
	fiasco.

	The search strategy was modified as reaction to RFC 1535.
	It however need to be modified further.  I've been arguing
	this for years.  Getting others to see the issue has been
	a problem.

	Remember when RFC 1123 and RFC 1535 were written the search
	strategy was to try the entered name last.  That also ment
	you often needed to skip across wildcard MX records so the
	search didn't stop on a NODATA response.

	If we had though to stop on NODATA as well as trying the
	name as entered first when it had multiple labels than I
	suspect there wouldn't be a issue now.  However the changes
	in response to RFC 1535 didn't do that and we need a RFC
	that describes how to do searching correctly.