Subject: RE: Scoped Addressing Architecture Routing Issue

From: "Scott Millington (BCT)" <[email-masked]>
Date: Tue, 1 Aug 2000 21:36:40 +0200

WHOA!!!

Please, if we can't debug network problems then your applications won't work anyways.  Is correct, interpretable ICMP traffic too much to expect??

Remember you are to an extent engineering for the lowest common denominator...Not me, I am a god ;)

The people most in need of the ICMP function are the ones that get called in as consultants when the local gumby has made a mess...WE NEED THIS FUNCIONALITY!!

Sincerely,
Scott Millington
Data Communications Architect
+++++++++++++++++++++++++
Ericsson Infrastructure Services
Corporate Network - Basic EriNet
KI/BCT/I/ONF
Kistagången 4-4tr.
125 82 Stockholm
Telephone: +46-8-75 71667
Cellphone: +46-70-643 7897
Facsimile: +46-8-40 45550
EMAIL:  [email-masked]
URL:    work - http://www.ericsson.se
        home - http://haapis.zap.to
+++++++++++++++++++++++++
Disclaimer: When I say something 
it is just me saying something 
and it is probably wrong anyway.
Certainly nothing I post should 
be construed as a statement of 
Ericsson company policy.

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]]
Sent: 2000-08-01 15:59
To: Richard Draves
Cc: IPng Working Group
Subject: RE: Scoped Addressing Architecture Routing Issue

In the example that I gave, the network is not misconfigured.  
There is intra-site routing for an entire site, and there is a 
second site redundantly attached to the first site.

Are you implying that a mixed-scope packet always indicates
a misconfigured network?

I agree that being able to debug network problems is good, but
I think that it is less important than being able to successfully
route packets to their destinations.

Margaret

At 05:42 PM 7/31/00 -0400, Richard Draves wrote:
>I've thought some in the past about your proposal. It would mean, for
>example, that there would be no Destination Unreachable / Scope Exceeded
>ICMP error because the routing table lookup would be constrained so as to
>not exceed the scope of the source address.
>
>My conclusion was that in normal configurations, it wouldn't make a
>difference. But when a network is misconfigured, it would get in the way of
>debugging the problem because you wouldn't get the ICMP error.
>
>Rich
>
> > -----Original Message-----
> > From: Margaret Wasserman [mailto:[email-masked]]
> > Sent: Monday, July 31, 2000 12:26 PM
> > To: IPng Working Group
> > Subject: Scoped Addressing Architecture Routing Issue
> > 
> > 
> > 
> > I believe that there is a problem with the forwarding section
> > of the Scoped Addressing Architecture document (section 9).
> > 

[...]

--------------------------------------------------------------------
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: Margaret Wasserman <[email-masked]>
Date: Tue, 1 Aug 2000 09:59:25 -0400

Margaret

[...]

---

From: Richard Draves <[email-masked]>
Date: Tue, 1 Aug 2000 18:16:15 -0700

> >Your example also has the best route between H1 & H2 in site 
> B, be to go
> >through site A. This seems really unlikely to occur in 
> actual practice. You
> >seem to be implicitly assuming that the two sites are in a single IGP
> >routing domain.
> 
> I am assuming that two sites _may_ be in the same routing domain, and
> that problems could occur in that situation.  I don't believe that the
> current IPv6 specifications assume that a single routing domain will 
> always be a single site.  

It's not assumed, but I think it will be uncommon to have two sites in a
single IGP routing domain and when it does occur the admin will have to take
care to avoid bad results in situations like you described.

> My example packet could easily occur in response to a packet sent from
> a host that doesn't have a site-local address (perhaps because it was
> configured via DHCP?).  That host would need to use a global 
> address to 
> communicate with a site-local address, and the response would have
> a site-local source and a global destination.  

The address selection rules try really hard to avoid mixed-scope packets. It
will happen if there's a host that has a global address but no site-local
address trying to communicate with a host that has a site-local address but
no global address. I think the presence of a mixed-scoped packet generally
indicates some problem somewhere.

> The ICMP issue that you have described would also exist when using 
> multiple "conceptual" routing tables in the case of a partitioned 
> site.  For example:
> 
> ==========================================================
> SITEA
>        Host1                      Host2
>          |                          |
> ________|__.__._____  ____.______._|_____________
>    Link1    |  |           |      |     Link2
>             |  |          (down)  |        
>             |  +-----R1----+      |
>             |                     |
>             |                     |
> ===========|=====================|=========================
> SITEB      |                     |
>             +--------R1-----------+
> 
> ===========================================================
> 
> If a site-local packet (site-local destination and site-
> local source) is send from Host1 to Host2, it would
> probably be sent to the local router, R1.
> 
> R1 would then use the scoped addressing rules to forward the 
> packet.  First, he would look at the destination address
> to determine that he should look in the site-local table.
> The site-local table would have no active route to Link2,
> so he would send a Destination Unreachable/No Route 
> To Destination message, _not_ a Scope Exceeded message.

This sounds right... a link is down, so you get no-route-to-destination and
you know what to start looking for.

> In this case, it might actually be _useful_ for the sender 
> to receive a Scope Exceeded message, because the sender might 
> be able to switch to global communication.  The sender may 
> have had both site-local and global addresses available, but
> have chosen site-local communication.  But, he doesn't get the
> Scope Exceeded message, so he can't act on it.

If the sender is trying to open a TCP connection, and their user-level code
is smart enough to iterate through the destination addresses that it got
back from getaddrinfo(), then the sender will first try the site-local
destination (using its site-local source address) and then when that
connect() fails it will fall back to the global destination (using its
global source address). The ICMP error isn't relevant to this to because TCP
treats the ICMP errors as soft errors.

Rich