Subject: RE: Some IPv6LL operational experience

From: "Bound, Jim" <[email-masked]>
Date: Thu, 21 Aug 2003 22:43:20 -0400

Josh,

Your describing a scenario for operations I believe is similar to ND,
Addrconf, Router Communications, DHCPv6, et al and using LLs for
Firewire or IEEE 1394 or USB are clear correct use of IPv6.  No
disagreement from me technically and the company I work for builds lots
of devices like this too.  It is a clear advantage of IPv6.  I never
said it was not.

But those who take this same argument you have provided so well and then
extrapolate that its ok to use SIP, SQUID, Streaming Media, Oracle et al
in the Enterprise for Ipv6 with LLs is a stretch and I would argue
missing the point.  

So what you state I agree with.  But as Keith has stated they are not
useful as app use adress.

Now I am hearing this "ad-hoc" generalization and no technical depth or
explanation.  That I do not buy and consider it sophist rhetoric in the
debate thus far and await some real technical input.

thanks
/jim

> -----Original Message-----
> From: Joshua Graessley [mailto:[email-masked]] 
> Sent: Thursday, August 21, 2003 1:24 AM
> To: [email-masked]
> Subject: Some IPv6LL operational experience
> 
> 
> 
> I realize that as an employee of a company that sells a product and 
> tries to implement standards the IETF blesses to solve problems, my 
> voice doesn't really count, but I wanted to toss in my two cents.
> 
> We have been using IPv6LL addresses with some success. The 
> next release 
> of Mac OS X implements something similar to LLMNR that we call mDNS 
> with support for IPv6. For the time being, the only IPv6 
> addresses we, 
> or most of our customers have, are IPv6LL addresses. This combination 
> of mDNS and IPv6LL addresses works very well. IPv6LL addresses are 
> important to us because a multi-homed host may not have an IP address 
> on every interface. IPv4LL addresses don't work on more than one 
> interface because they lack a scope id. The scope id in IPv6LL 
> addresses makes them much more compelling.
> 
> IPv6LL addresses let us enable networking in situations that wouldn't 
> otherwise work. For example, we've implemented IP and IPv6 over 
> Firewire. In most cases, it is unlikely that an IPv4 address will be 
> assigned to the IP over Firewire link. This is usually used in the 
> scenario where two computers are hooked directly together. We can't 
> assign an IPv4LL address to the Firewire interface because it 
> causes a 
> number of problem on a multi-homed host. The IPv6LL address is 
> configured automatically and is always there. Very few people 
> have the 
> skill required to successfully type an IPv6 address, which is why the 
> mDNS component is so important. In addition to allowing users the 
> ability to type a name instead of an address, the question of 
> scope id 
> goes away. The name is resolved using mDNS. The scope id is derived 
> from the interface the response came back from. The 
> application is none 
> the wiser because it gets a full sockaddr_in6 from the call 
> to resolve 
> the name.
> 
> Applications that perform referrals may fail, but I'm not 
> aware of any 
> of these that are currently shipping and support IPv6. IPv6 is a new 
> beast, we don't have to be as concerned about applications making 
> stupid assumptions. If we explain that IPv6 link local addresses work 
> this way and here's a list of limitations, that's good enough. The 
> advantages of IPv6 link-local addresses far outweigh the 
> disadvantages.
> 
> IPv6LL is a major selling point. IPv6LL is a sneaky way to 
> get everyone 
> exposed to IPv6 and to encourage developers to start supporting IPv6. 
> Sure, connectivity off of the local link for those of us in the US is 
> only for a few elite, but IPv6 on the local link can solve real world 
> problems today and work for everyone.
> 
> -josh
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 

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

---

From: "Michel Py" <[email-masked]>
Date: Thu, 21 Aug 2003 21:05:52 -0700

> Jim Bound wrote:
> The reason NAT got away with what it did is the users got
> blind sided and then IETF got sucked into building a special
> NAT working group (which I objected to at Munich) and look
> at the mess we have out there today.  At least to me it's a
> complete mess.

I have to disagree with this. The reason NAT is popular is not because
users are stupid. Users indeed are stupid (count me in, I use NAT) but
they will continue using NAT as long as the pros outweigh the cons. It
is too late to do anything about IPv4 NAT, but if we see IPv6 NAT
happening it will be our collective failure to provide solutions that
are better.

Michel.

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 22 Aug 2003 00:15:58 -0400

Keith,

I agree yet again on your scaling well put statements below.  I thought
of that and between the lines when I said "how does the user know which
interface" I was really addressing the scalability issue.  But awhile
ago I came to realize that the only time that argument works is when it
is used as filerbuster to hold up engineers work in the IETF and I have
seen it used on a few specs.  A good example I gave up on was router
preferences for IPv6 I argued we had to have them but got shot down
based on ones reputation.  I think everyone one of us do router
preferences with ND in implementation as Hosts today and just got it
done. We could have done so much more with ND had we looked at router
preferences but all at that time in the IPv6 world were anti-hosts
knowing anything about IPv6 and I believe anti-servers for operations
(e.g. DHCPv6, Service Location) and why we still have not completed DNS
Discovery in the IETF.  So I gave up on using scalable hypothesis in
debate.  What I tried here was simple common sense with some network
diagrams and such.  Then folks started screaming "but Jim this ipv6
advantage".  Of course it is but not for applications use.
But LLs will not scale.

P.S. the one that still drives me nuts is when someone tells me I have a
packet built in my kernel where the source has less scope than the
destination address, just send it anyway? Don't get it and never will
:--).

/jim

> From: Keith Moore [mailto:[email-masked]] 
> Sent: Friday, August 22, 2003 12:02 AM
> To: Bound, Jim
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: Some IPv6LL operational experience
> 
> 
> On Thu, 21 Aug 2003 23:44:37 -0400
> "Bound, Jim" <[email-masked]> wrote:
> 
> > I came here and asked a simple question.  Look what happened.  In 
> > industry this would be a no brainer and most would take 
> your view is 
> > my opinion.  Don't use these for applications. But it has 
> turned into 
> > another absurd avoidance of basic principles because folks 
> have their 
> > heals dug in on for some reason.
> 
> As far as I can tell, the "reason" is a basic failure to do 
> engineering, or more specifically analysis.  A small number 
> of emperical tests with limited scope are taken as evidence 
> that some practice or another will not cause problems for an 
> extremely diverse Internet with 10**8 - 10**9 distinct users 
> and 10**5 - 10**6 different apps.  That's the networking 
> equivalent of driving a single car over the original Tacoma 
> Narrows Bridge and declaring it sound.
> 
> (I cite the Tacoma Narrows Bridge because it was another case 
> of ignoring the analysis that was done (of wind effects) - 
> blind faith in the designer's reputation was deemed to make 
> such analysis irrelevant.)
> 
> Keith
> 
> p.s. If you're not familiar with that bridge,
> see http://www.camerashoptacoma.com/mpegs/TacomaNarrowsBridge.mpg
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 22 Aug 2003 00:18:38 -0400

100% agree. I was stating the tremor before IPv4 NAT actually happened
not why they are using it.  I also don't think users are stupid but
maybe far to trusting of vendors and the IETF like MObile IPv6 WG was of
IPsec :--)

/jim

> From: Michel Py [mailto:[email-masked]] 
> Sent: Friday, August 22, 2003 12:06 AM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: RE: Some IPv6LL operational experience
> 
> 
> > Jim Bound wrote:
> blind sided 
> > and then IETF got sucked into building a special NAT working group 
> > (which I objected to at Munich) and look at the mess we 
> have out there 
> > today.  At least to me it's a complete mess.
> 
> I have to disagree with this. The reason NAT is popular is 
> not because users are stupid. Users indeed are stupid (count 
> me in, I use NAT) but they will continue using NAT as long as 
> the pros outweigh the cons. It is too late to do anything 
> about IPv4 NAT, but if we see IPv6 NAT happening it will be 
> our collective failure to provide solutions that are better.
> 
> Michel.
> 
> 
>

---

From: "Michel Py" <[email-masked]>
Date: Thu, 21 Aug 2003 21:25:24 -0700

Jim,

> Jim Bound wrote:
> 100% agree. I was stating the tremor before IPv4 NAT actually
> happened not why they are using it.  I also don't think users
> are stupid but maybe far to trusting of vendors and the IETF
> like MObile IPv6 WG was of IPsec :--)

What drives me nuts with you is that although you have a
far-better-than-average understanding on how the market works you have
failed to realize that users ultimately drive the market and these users
don't actually give a hoot to LLs but do to SLs.

Michel.

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 22 Aug 2003 00:40:06 -0400

Michel,

I do know this.  But I am here to make folks like you totally miserable
:--).

But seriously. When the parts get built as engineers we have the
responsibility to support the technical criteria for what the user don't
see in implementation and architecture.  In fact they trust us to do
that.  And incorrect use of LLs I strongly believe can hurt users as an
engineer/architect and SLs are well.............you now how I feel about
them as bad approach to solve what I think finally Bob Hinden has solved
with link-unicast-global draft.  That I can live with not SLs.  

What was my point of compromise for SLs in that past discussion before
this wise WG consensus deprecated them?  Ok age happens I will respond
:--).  PUT CONTROLS ON THEM SO THEY DON'T EVER LEAVE A SITE AND AGREE TO
THE RULES FOR THE SITE BORDER ROUTERS. But
nooooooooooooooooooooooooooo.......folks wanted to leave that open "just
in case" ergo support for free-for-all (I was never sure just in case
for what) and I will stop there.

There are times we need to leave things open ended SLs or LLs are not
one of them in my opinion.

So this has nothing to do with users we are behind the wall here.

/jim

> Sent: Friday, August 22, 2003 12:25 AM
> To: Bound, Jim
> > maybe far to trusting of vendors and the IETF like MObile 
> IPv6 WG was 
> > of IPsec :--)
> 
> far-better-than-average understanding on how the market works 
> you have failed to realize that users ultimately drive the 
> market and these users don't actually give a hoot to LLs but 
> do to SLs.
> 
> Michel.
>  
> 
>

---

From: "Michel Py" <[email-masked]>
Date: Sat, 23 Aug 2003 16:08:18 -0700

Jim,

> Jim Bound wrote:
> But seriously. When the parts get built as engineers we
> have the responsibility to support the technical criteria
> for what the user don't see in implementation and
> architecture.  In fact they trust us to do that.  And
> incorrect use of LLs I strongly believe can hurt users
> as an engineer/architect and SLs are well.......

That's the kind of reasoning that got you playing in the junior league
and forced you to adopt your competitor's proprietary protocols. Have
you configured an HP ProCurve L3 switch recently? The CLI is a very
incomplete and pale attempt at copying IOS and it even incorporates some
Cisco proprietary protocols such as CDP (Cisco Discovery Protocol).

Your company completely missed the boat on routers and switches, please
enlighten us why you think you are right this time?

> But I am here to make folks like you totally miserable :--)

I have a few dispositions for that myself.

Michel.

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 21 Aug 2003 22:50:02 -0400

folks,

I am not going to stay in what is ad-hoc network.  This is not well
defined it means different things to different users and different
vendors.  But I leave this discussion with my base view.

- Can be more than one link

- Network did not exist previously or was not known to other networks

- Routing may converge (manet) or be commanded by higher authority
(don't need manet or anything like it in the second case)

/jim

> Sent: Thursday, August 21, 2003 3:51 PM
> To: Charlie Perkins
> Cc: [email-masked]; [email-masked]
> > Something is wrong with the way you seem to be using the 
> term "ad hoc" 
> > network.  It doesn't have to be a single link.  There are lots of 
> > reasons to have a multihop/multi-technology ad hoc network.
> 
> I agree entirely that it's not desirable to expect ad hoc 
> networks to be a single link.  However, the proposals for ad 
> hoc networks I've seen tend to use ambiguous, and often 
> link-local, addressing.  
> 
> The zeroconf group attempted to justify v4LL addressing by 
> saying it was for ad hoc networks; now we see people trying 
> to justify application use of v6LL in ad hoc networks.  Both 
> are highly dysfunctional (v6LL is not quite as bad as v4LL, 
> but still not generally usable).
> 
> > >There's nothing wrong with using the packet format on an ad hoc 
> > >network, the problem is it's the expectation that apps 
> have that IP 
> > >equates to Internet access.
> > >
> > I thought apps were supposed to care about end-to-end data exchange,
> > regardless of whether the data is exchanged over one or many links.
> 
> Apps care about more things than end-to-end data integrity.  
> Some apps care about having consistent view of addressing 
> across all locations in the network.  Some apps also care 
> about having consistent naming across all locations in the 
> network.  IMHO IP-based ad hoc networks need to provide both 
> of these in order to be viable.

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 25 Aug 2003 22:49:53 -0400

John,

Very good response.  Lets go offline.  I think mdns should be revisited
from your mail in the IETF.

Thanks
/jim

> Sent: Sunday, August 24, 2003 12:50 AM
> On Aug 22, 2003, at 10:03 PM, Bound, Jim wrote:
> 
> > mdns or LLMNR are not widely implemented and if you bring your 
> > implementation to one of the many test events for IPv6 
> where your node 
> > must interoperate on the deployed implementations testing 
> network most 
> > nodes will not respond to mdns.  I am sure you can 
> interoperate with 
> > your own nodes.  But think about a network where your nodes 
> are only 
> > say 10 out of 30 on two links.  Your mdns will not work 
> with the other
> > nodes
> > for IPv6LLs.
> 
> We are trying to push for a wider adoption of mDNS. We were trying to 
> work with the IETF to establish it as a standard, but the 
> working group 
> ran it in to the ground as LLMNR to such a state that we can not use 
> it. We continue working on mDNS since LLMNR is in such a 
> useless state. 
> Our implementation of mDNS can be built on many platforms. We 
> feel that 
> mDNS combined with IPv6LL addresses make for a very powerful solution 
> to the problems of local communication on both configured and 
> unconfigured networks.
> 
> > My postulate is that major pain can be caused by sending to 
> the wrong 
> > IPv6LL in a multilink scenario if the packet goes to the 
> wrong link. 
> > How does the user know to specify applicationname 
> FE80::1%ethernet0, 
> > ethernnet1, etc.?
> 
> On our implementation, if the scope is not specified the transmit 
> fails. I think it results in a no route to host error. This 
> means that 
> the scope id must be specified for a link-local address. In 
> the case of 
> mDNS, this is automatic. In the case of manually typing an 
> address, the 
> user must append the scope id to the IPv6LL address (i.e. 
> fe80::123%en0). Some browsers choke on this, treating the % as an 
> escape character. Most browsers handle this correctly when the IPv6 
> address is correctly bracketed by '[' and ']'.
> 
> > Because of this potential conflict today it needs to be documented 
> > publicly.
> >
> > That does not mean in worst case scenarios of no router and no 
> > assigned prefix for ad hoc network IPv6LLs cannot be used 
> but rather 
> > some serious thought should go into their use by what I 
> call mission 
> > critical applications.
> 
> Suggesting that applications should avoid IPv6LLs at all cost 
> is silly. 
> IPv6LLs will work transparently with the vast majority of existing 
> applications. Applications that have special requirements (those 
> transmitting an address in a packet) will need to filter out such 
> addresses for any destination that may potentially be off link. Those 
> applications may also need to remember the interface packets were 
> received on in the case of an IPv6LL being forwarded to 
> another node on 
> the same link, just as our mDNSResponder and resolver libraries do. 
> This is not a difficult concept to grasp nor is the code very 
> complicated. I'm surprised it has sparked such a heated debate.
> 
> -josh
>