Updated IP Forwarding MIB

[Brian Haberman]

All,
I have just submitted an update to the IP Forwarding MIB
that addresses all the last call comments.  If you cannot wait
for the I-D editor announcement, a copy is availale at
http://www.innovationslab.net/~brian/drafts/fwdmib.txt.
Regards,
Brian

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 PROTECTED]

Random algorithm in draft-ietf-ipv6-unique-local-addr-00.txt

[Brian Haberman]

There have been several comments on eliminating the
user input portion of the random selection algorithm.
This would, primarily, provide the capability to
automate the prefix generation process.  After assessing
issues with this, I have two possible proposals:
1. Re-use the random ID process defined in Appendix A.6
  in RFC 1889.  That algorithm derives a 32-bit number
  from the system clock, system name, process ID, and
  several other system-related IDs.  It would have to
  be modified slightly to provide a 40-bit value.
2. Replace the user-supplied birthday value with a system
  derived value (EUI has been suggested).  The system
  clock would still be utilized as a portion of the input
  to MD5.
It should be noted that #1 will return the same value on
repeated calls until the system clock changes or a different
value is passed in as a parameter.
At this point, my preference is for #1, since it has been
tested as a part of RTCP and the probability function is
well-defined in the rfc.
If others have differing opinions, let me know.

Thanks,
Brian H.

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 PROTECTED]

Re: Comments on draft-ietf-ipv6-unique-local-addr-00.txt

[Brian Haberman]

Hi Geoff,

Geoff Huston wrote:

I see that the local use address draft has been revised and published 
as a WG
document.

In section 3.2.2 of the draft, it notes that, in reference to Locally
Assigned  Global IDs that  "the likelihood of conflict is small. "
I had noted in draft-huston-ipv6-local-use-comments-00.txt that  the
likelihood of conflict is given by  the formula:
P = 1 - ((n!)  / ((n**d)(n-d)!))

where n = 2**40 and d is the number of random 'draws' from the pool.

The likelihood of conflict exceeds 0.5 after only 1.24 million draws. I'd
contend that this is definitely not "small" as described in the draft. 


My disagreement with this calculation is two-fold.

The first issue I have is that these addresses are not meant to be routed
globally, so there is an additional variable that needs to be considered
when calculating P for collisions.  That is, the P above needs to take into
account the probability that two networks trying to use the same prefix are
connected.
My second issue is with the formula itself.  RFC 1889 uses an MD5 hash for
calculating its SSRC Identifier (a 32-bit number).  That document states:
 the probability that two sources independently pick the same value
 can be approximated for large N [20] as 1 - exp(-N**2 / 2**(L+1)).
 For N=1000, the probability is roughly 10**-4.
N represents the number sources (number of entities making a random 
selection)
and L is the length of the identifier.  I see this formula being more 
representative
of the probability of collision.

Regards,
Brian H.

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 PROTECTED]

Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-03.txt

[Brian Haberman]

Mike,
 Thanks for the comments.  I have a few follow-ups in-line...

1.) The rationale for adding inetCidrRouteDiscards (and deprecating
ipRoutingDiscards in 2011-update) is not documented.  While I don't
entirely agree with that decision, I can accept it based on the
following explanation from Bill Fenner:

On Fri, 31 Jan 2003, Bill Fenner wrote:
Bill> The IP-MIB revision (draft-ietf-ipv6-rfc2011-update-01.txt)
Bill> deprecates ipRoutingDiscards and ipv6DiscardedRoutes in favor
Bill> of inetCidrRouteDiscards. The thought was that you can't tell
Bill> whether an ipRouteDiscards counts v4-only (as it would if a
Bill> system implemented RFC2011+2465) or both, so it's better to
Bill> define a new object with well defined semantics.  If we
Bill> decide that's not a good justification, we should remove
Bill> inetCidrRouteDiscards and un-deprecate ipRouteDiscards in
Bill> 2011-update.
Since the point has been controversial, I would like to suggest that
some text along these lines be added to the narrative part of the
document, perhaps in the required but as-yet unwritten "Changes from
RFC 2096" section (see item (6) below).  I would also like to
suggest that the object's DESCRIPTION clause be change from:
 inetCidrRouteDiscards OBJECT-TYPE
 SYNTAX Counter32
 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION
"The number of routing entries which were chosen to be
 discarded even though they are valid.  One possible
 reason for discarding such an entry could be to free-up
 buffer space for other routing entries."
 ::= { ipForward 8 }
to:

 inetCidrRouteDiscards OBJECT-TYPE
 SYNTAX Counter32
 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION
"The number of entries in the inetCidrRouteTable which
 were chosen to be discarded even though they were valid.
 One possible reason for discarding such an entry could
 be to free up buffer space for other routing entries."
 ::= { ipForward 8 }
to make it perfectly clear exactly what is being counted.
I agree with the proposed text.  In addition, I will add some
description to Section 4 describing the relationship between
this object and the deprecated object in the 2011 update.
2.) inetCidrRouteNumber has not been re-instated, but there are
still a number of references to it in the document.  Either it
should be re-instated with the following definition:
 inetCidrRouteNumber OBJECT-TYPE
 SYNTAX Gauge32
 MAX-ACCESS read-only
 STATUS current
 DESCRIPTION
"The number of current inetCidrRouteTable entries that
 are not invalid."
 ::= { ipForward 6 }
or else the dangling references to it should be removed from Section
4 and from the DESCRIPTION clause of ipCidrRouteNumber. In the
latter case the OID assignments under ipForward should also be
reshuffled to avoid gaps in the assignments (e.g., by changing the
sub-ID assigned to inetCidrRouteDiscards to 6 from 8).
My very strong recommendation is to re-instate the object.  I'll
note that there was agreement on this point in the e-mail that I
quoted above:
I agree.  I will re-instate inetCidrRouteNumber.


On Fri, 31 Jan 2003, Bill Fenner wrote:
Bill> I agree that there should be an inetCidrRouteNumber.

The reason for wanting a summary counter is because the potentially
huge size of the inetCidrRouteTable makes it inefficient (and
probably infeasible) for a manager to derive that information by
downloading the whole table.
The arguments quoted for its removal -- namely, that it may not
agree with the count of the in-view rows for some users and that it
may be difficuly for distributed agents to implement -- are, in my
opinion, irrelevant and unconvincing, respectively.  Focusing on the
latter, the distributed agent implementation problems are not
insurmountable, and in any case must be weighed against the problems
caused for managers.  And as Mike MacFaden has pointed out, agents
already have to solve that problem anyway for ipCidrRouteNumber --

On Fri, 7 Feb 2003, Mike MacFaden wrote:
MM> Another thing not considered in Margaret's latest 2096
MM> replacement draft is that both rfc2096 and its successor are
MM> both active in the same agent at the same time.
MM> 
MM> So I think ipCidrRouteNumber will apply
MM> to both the existing and replacement table regardless,
MM> it will just be a count of the ipv4 routes...

When this issue came up back in February there was a discussion on
the mreview mailing list, and contrary to some reports there is no
consensus among the MIB doctors that summary objects like these are
evil.  See the thread "ifNumber and its ilk considered harmful" at
this URL: http://ops.ietf.org/lists/mreview/mreview.2003#00159
The rest of what follows below are MIB doctor-type nits.

3.) Normative references for some MIB modules that appear in the
IMPORTS list are missing.  They are:
MIB moduledocument

IF-MIB   

Re: Draft on Globally Unique IPv6 Local Unicast Addresses

[Brian Haberman]

Bob Hinden wrote:
Brian,

At 04:22 AM 5/27/2003, Brian E Carpenter wrote:

Now, as a pragmatist, I would probably settle for a pseudo-random
and probably-unique /48, but not everybody will. I can just imagine a
phone call in which I recommend to IBM's chief network architect to use
address space that *probably* nobody else is using.
Do other people think we need a guaranteed-unique mechanism
for limited-scope addresses, or is probably-unique enough?


My take on the discussion is that we need both.  There are organizations 
who prefer to go to a registry to get some guarantee of uniqueness and 
others who prefer to generate a prefix themselves.
I agree.  There are justifications for both approaches.

Your earlier suggestion of

I wouldn't have a problem with a variant of Bob's proposal in which
(for example) FC00::/8 is followed by a 40 bit ID allocated as Bob
suggests, and FD00::/8 is followed by a user-assigned 40 bit ID.
Then FC00::/7 would be the prefix for all limited-scope addresses.


appears to be a reasonable approach where the 40 bit ID under FD00:/8 
would be selected by running an algorithm that would have to be specified.
Yes.  Not a hard algorithm to come up with either.

There is a clear tradeoff between a longer ID (to allow for better 
random numbers or MAC addresses) and the size of the subnet field.

Before revising the draft, I would prefer to hear from more people on 
these tradeoffs.
I like Brian C.'s alternative suggestion.

Regards,
Brian

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 PROTECTED]

Re: My Thoughts on Site-Locals

[Brian Haberman]

Erik Nordmark wrote:
Correct.  My statement was for the protocol, not the forwarding.
That is why I made the follow-on comment about complexity.  The
next-hop interface's ifindex for the global destination address
would have to be checked to ensure that it has the same zone ID
as the interface on which the packet was received.  So, it leads
to more checks during forwarding AND requires the forwarding table
to potentially maintain multiple next-hops for the global addresses.


I don't think that is sufficient.
If all the entries in the RIB for the prefix point outside the site
then you have no choice but to drop the packet on the floor.
If the sender had used a global source the packet would have made it
through.
Yes.  I agree that would happen.  That is why it has an operational
component as well.  Lets say we have something like this:
+ Internet -+
|   |
 office1 -- site local / --- office2
  global
A node in office1 could communicate with a node in office2 using
any combination of SLs and Globals (per the existing specs) as long
as both offices were in the same site.  Using your example of
global dest and SL src, everything is fine until the internal link
breaks.  Now, the source node would get back a "scope exceeded"
ICMP message when the router tries to send the packet over the
Internet.  So now the source picks a global src to go with the GL
dest.  The packet may get through unless the routers or firewalls
drop it when they realize that the destination is really inside
but isn't reachable.  If it does get through, then the source may
have sent sensitive information over the Internet without encrypting
it.
What I am saying is that the routing and forwarding can be made to
work, but it is kludgy and a big impact on performance.
Brian


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 PROTECTED]

Re: My Thoughts on Site-Locals

[Brian Haberman]

Erik Nordmark wrote:
 Each zone is required to be "convex" from a routing
 perspective, i.e., packets sent from one interface to any
 other interface in the same zone are never routed outside
 the zone.
No one has objected to it.  I have implemented the routing of
scoped addresses.  I can guarantee convexity in the protocol.


Brian,

I thought the hard part about ensuring convexity wasn't about the routing
protocol itself, but ensuring convexity in the forwarding of a packet
with
dst = global address assigned to site
src = site local address
For things to work such a packet must stay inside the site even though
it's destination address is a global address.
Correct.  My statement was for the protocol, not the forwarding.
That is why I made the follow-on comment about complexity.  The
next-hop interface's ifindex for the global destination address
would have to be checked to ensure that it has the same zone ID
as the interface on which the packet was received.  So, it leads
to more checks during forwarding AND requires the forwarding table
to potentially maintain multiple next-hops for the global addresses.
In other words, the global prefixes learned from within the site
have to be "marked" so they don't get confused with prefixes
learned from outside the site.
Brian


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 PROTECTED]

Re: Why I support deprecating SLs

[Brian Haberman]

Thomas Narten wrote:
Hi James.


However, I believe some of the resistance to deprecation may be the
result of people who have implementations and would rather not have
to pay the costs of ripping out that code and putting in something
new.


This I don't understand. AFAIK, there is little or no code to rip
out. And if the code is there, but no site-locals are actually
configured or assigned to nodes, any code related to site-locals
doesn't get executed and is harmless. So I don't see what problem
there is with deprecating them with regards to existing
implementations. I don't imagine anyone is going to say we need to put
wording in some spec that makes existing implementations that have
code related to site-locals be declared non-conformant. That would be
silly.
Do folks think this above is a significant issue?
So, as most of you probably know, I have implemented a router that
supports scoped addresses (unicast and multicast).  If I still
supported that box, I would be quite happy to rip the support out.
If someone wants to see a presentation on what I did, go find the
proceedings from the routing area meeting in Atlanta.
I can see where implementations like John Bartas' could have
support issues when customers can't align code with RFCs.  But,
I would rather deal with that scenario than trying to debug
operational problems with site locals.
I would like to hear from other people who have actually implemented
SL support, and I mean ALL of the support (routing/forwarding, apps,
dns, firewalls, mobility, etc.).
Regards,
Brian

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 PROTECTED]

Re: My Thoughts on Site-Locals

[Brian Haberman]

and it isn't clear how we can ever finalize the scoped
addressing architecture without some type of decision
on this issue.  Perhaps we can break out the
non-contentious parts and advance those parts?

We need to break out some of it regardless.  If everyone recalls,
I pointed out that pieces of the scoped addressing architecture
still needs to be done in order to support the scoped multicast
addresses.
I believe we can progress on three topics:
- Ambiguity
- Convexity / defining the site borders.
- Tuning the compromise.
I can comment on the convexity issue.  Section 5 of the scoped
addressing architecture has the following:
 Each zone is required to be "convex" from a routing
 perspective, i.e., packets sent from one interface to any
 other interface in the same zone are never routed outside
 the zone.
No one has objected to it.  I have implemented the routing of
scoped addresses.  I can guarantee convexity in the protocol.
Does it work?  Yes.  Is it a performance hit?  Absolutely.
And as Alex pointed out in another message, the complexity gets
worse when scope boundaries have to be reflected in area borders.
Unfortunately this requires people that are for IPv6 and not against and
that are willing to compromise. I regret to report that at this point I
count only three: Bob Hinden, you and me.
Quite an insulting comment.

Regards,
Brian

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 PROTECTED]

Re: dns discovery for agenda? [Re: chairs and charter]

[Brian Haberman]

Erik,

Erik Nordmark wrote:
If we have statefull address autoconfig & stateful address autoconfig, I
think having an additional mechanism for getting DNS server addresses is not
a  bad thing.  At the transport layer, we have UDP, UDP-lite, DCCP, TCP,
SCTP ... to transfer packets.  Having multiple ways to do something is a
reasonable solution.


Two issues with multiple methods to configure the same thing that
hasn't been brought up are:
 - potential impact on time to discover
Since each router advertisement doesn't need to contain all
options will a host need to listen for RAs for some time
before it decides it to DHCPv6 to find the info?
 - conflicting information
A host might use DHCPv6 for other reasons/other information.
What should it do if the RAs and the DHCPv6 reply contains
different DNS information?
What if different RAs received on the same interface contain
different DNS information?
A few points on your last issue.  The NDP spec does state that if
two routers detect conflicting info in the RAs that they should
log a warning.
That approach will help the operator with fixing the conflicting
info, but doesn't benefit the nodes that are receiving that info.
For them, perhaps what we should do is state that they should
honor the RA coming from the router with the lowest IPv6 address.
By doing that, operators can assign some level of priority to
their RAs.
Regards,
Brian

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 PROTECTED]

Re: Question about IPv6 Management

[Brian Haberman]

Eric,
 Take a look at the following:
draft-ietf-ipv6-rfc2096-update-02.txt
draft-ietf-ipv6-rfc2013-update-00.txt
draft-ietf-ipv6-rfc2012-update-02.txt
draft-ietf-ipv6-rfc2011-update-02.txt
Regards,
Brian
EricLKlein wrote:
Thank you. I have been reading:
RFC 2452 IP v6 MIB for the TCP
RFC 2454 IP v6 MIB for the UDP

RFC 2466 MIB for IP v6 ICMP 

But didn't see anything more detailed. Thanks for the information.
Eric
  - Original Message - 
  From: Wijnen, Bert (Bert) 
  To: EricLKlein ; [EMAIL PROTECTED] ; [EMAIL PROTECTED] ; [EMAIL PROTECTED] 
  Sent: Monday, March 17, 2003 2:48 AM
  Subject: RE: Question about IPv6 Management

  We have been defining a number of things so that IP (or better Internet) 
addresses
  can be represented in an IPversion neutral matter. See for example RFC3291.
  We are checking all MIB modules to be IPv4 and IPv6 capable (unless a module
  is for one specific IP version). 

  We have defined TCs so that we also have IPv6 transport addresses so that 
  SNMP can go over IPv6. See RFC3419

  Various MIB modules are being reqorked in the IPv6 WG 

  Hope this helps
  Thanks,Bert 

-Original Message-
From: EricLKlein [mailto:[EMAIL PROTECTED]
Sent: zondag 16 maart 2003 11:19
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Question about IPv6 Management
I appologize, this is being possted to multiple WG's as it seems to cross areas.

Is there any information about the requirment changes in the Network Management Systems (NMS) or Operations Support Systems (OSS) necesary to support IPv6?

I have looked at the various MIB RFC's and such, but can not find anything more than you need bigger address support and some SNMPv2 compliance.

This seems too simple to me.

 Eric


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 PROTECTED]

Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery]

[Brian Haberman]

Pekka Savola wrote:
On Sat, 8 Mar 2003, Tim Chown wrote:

On Sat, Mar 08, 2003 at 06:45:15PM +0200, Pekka Savola wrote:

No comments from the w.g. except by me and the author.

RA-piggybacking has a few different nuances, and I'm not sure if I think
the one proposed is necessarily the best one, but it's the one group of
solutions I'd probably follow up if I wanted to achieve something.
I'd like to see it kept on the table.  I appreciate it has security issues,
but then all the tabled methods do too?


Actually, the security properties of RA-piggybacking solutions are roughly 
on the same level as with DHCP and friends, not to mention general 
connectivity.

The only attack model with RA-piggybacking that might make sense is to 
inject a spoofed RA containing your rogue DNS servers instead of hijacking 
all the connectivity.  This might be more difficult to notice than all net 
access being man-in-the-middle -attacked on the link by a node.

But then again, the above case hasn't been mentioned in any analysis I
recall (just made it up), so it's difficult to say.  I certainly don't
feel there are a lot of issues with security in RA-based DNS discovery.
I believe section 6.2.7 of RFC 2461 will help catch this kind of attack.
If the routers on the link validate the parameters being sent by other
routers in their RA's, the spoofed RA should be detected.
Brian


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 PROTECTED]

Re: Question on MLD

[Brian Haberman]

Markku Savela wrote:
RFC 2462 says that the node MUST join the solicited-node
multicast group (which implies using MLD) when performing
DAD.


Presumably it needs to do the MLD join with ::-src address, because
before DAD address is not yet valid.
That is exactly what draft-ietf-magma-mld-source-04.txt is
intended to correct.  That draft is in front of the IESG at
this time.
Personally, I think the spec is just plain wrong. I believe one should
not use MLD on link local multicast groups.
As I pointed out in an earlier message, MLD messages are necessary
in order to deal with MLD snooping switches.
Brian


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 PROTECTED]

Re: Question on MLD

[Brian Haberman]

Siva Veerepalli wrote:
At 02:32 PM 2/27/2003 -0500, Brian Haberman wrote:

MLD-snooping switches is the biggest reason.


Ok. So, it seems like there would be no need to send these reports for 
link-local multicast on point-to-point links. Should this clarification 
be made in the IPv6 over PPP RFC?
How many implementations of MLD pay attention to the link-type
of the interface?  All the MLD codebases that I have seen are
interface-type agnostic and treat them all the same.  I don't
see the benefit of revving RFC 2472 to change this behavior.
Regards,
Brian

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 PROTECTED]

Re: Question on MLD

[Brian Haberman]

MLD-snooping switches is the biggest reason.

Brian

Siva Veerepalli wrote:
RFC2710 (MLD) states that when a General Membership Query is received, a 
node listening to the query sends a membership report for all multicast 
addresses it is listening to, excluding the all-nodes link-local 
multicast address and any multicast addresses of scope 0 (reserved) and 
1 (node-local).

My question is, is the node required to send the membership report for 
solicited-node multicast address as well? In general, since nodes do not 
receive link-local scope multicast packets from out side the link, why 
is it required for the nodes to report membership to the router for 
*any* link-local scope multicast addresses?

Thanks,
Siva

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 PROTECTED]


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 PROTECTED]

Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format forthe 2000::/3 Prefix"

[Brian Haberman]

I agree that Informational is the correct level.  I also
don't see anything in the doc that is "new" and needs to
be a Standard.

Regards,
Brian

Thomas Narten wrote:

Yes. Obsoleting 2374 is (from what I can tell) the point of this
document. IMO, putting more into the document than needed to achieve
just this is a distraction.




I really don't find that the text you are objecting to is a distraction.
I think it makes the draft more comprehensible. But it's a judgement
call, so I'd like some other people to comment.



Agreed.

Trying to make this document a Proposed Standard is what makes me
uncomfortable. There is nothing in it that is defining anything new in
a standard's sense (at least, AFAIK).  If it were informational, this
issue would just go away.

I guess some are arguing informational is not a strong enough signal,
but I don't personally agree with that. Reclassifying a document as
historic, and obsoleting it seems pretty clear to me.

[side note: the MUST/MAY definitions can now be removed as they are no
longer used.]

Brian E Carpenter <[EMAIL PROTECTED]> writes:



Let me ask a pragmatic question. If this document goes on standards
track, how will this document advance up the Standards Track? What
will the implementation reports contain and actually test? I don't see
immediately anything that is testable. This is one of the reasons I
don't see Standards Track is being the right classification.




Good point (but doesn't it also apply to the address architecture
to a large extent?). BCP is our usual way out of that.



Similar reasoning applies to addr arch. I think that making it a BCP
might in retrospect also have been an alternative approach.  But, that
document also has a lot more in it, so it's easier to find stuff in
that is clearly implementation related. But there is also pieces where
the connection is not immediately obvious...

Thomas

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 PROTECTED]






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 PROTECTED]

Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt

[Brian Haberman]

Jari Arkko wrote:

[EMAIL PROTECTED] wrote:


Hi Brian(s);



My concern is the scenario where an operator knowingly disables
prefix advertisements and enables DHCPv6.  If the nodes doesn't
do DHCP, it is stuck with only the link-local address.



Understood. That certainly deserves a health warning. But in large
scale deployments of low-end devices, implementors need to feel
free to leave DHCP out. 



Just a small comment - 2462 (stateless aa) is a MUST.  Additionally,
manual configuration is always a possibility as well.  If certain
hosts know they don't need DHCP, then I don't see the problem of
having DHCP as a MAY.
In general, stateless address autoconfig is a good thing, so we want
to encourage service providers to do the right thing.



Maybe the right thing is to attach a warning or an explanation
about the implications and leave the support as a MAY. For
instance,

  "Nodes that do not implement DHCP may become unable to
   communicate outside the link when their routers advertise
   stateful autoconfiguration and no prefixes suitable
   for stateless autoconfiguration are offered."


If that type of text is in the doc, I will support a MAY.

Brian


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 PROTECTED]

Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt

[Brian Haberman]

Brian E Carpenter wrote:

Brian Haberman wrote:


[EMAIL PROTECTED] wrote:


Hi Ralph,

The text looks really good, what do other thinks?  Does anyone
have a preference for Stateful Address Autoconfiguration to be
a SHOULD or a MAY?


I tend to agree with the SHOULD.  Since these nodes recognize the
'M' & 'O' bit-settings, they should be capable of acting on their
settings.

Brian



Does that follow? DHCP strikes me very much as a discretionary
thing. I think vendors will know when to support it, so a MAY
seems enough to me.


My concern is the scenario where an operator knowingly disables
prefix advertisements and enables DHCPv6.  If the nodes doesn't
do DHCP, it is stuck with only the link-local address.

Brian


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 PROTECTED]

Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt

[Brian Haberman]

[EMAIL PROTECTED] wrote:

Hi Ralph,

The text looks really good, what do other thinks?  Does anyone
have a preference for Stateful Address Autoconfiguration to be
a SHOULD or a MAY?


I tend to agree with the SHOULD.  Since these nodes recognize the
'M' & 'O' bit-settings, they should be capable of acting on their
settings.

Brian


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 PROTECTED]

Re: a few comments on anycast mechanisms

[Brian Haberman]

Susceptibility to DoS attacks is another consideration that needs some
attention, I think. The RR mechanim in MIPv6 is designed to require no
state in CN, but in the anycast RR mechanisms the roles are reversed:
here the anycast server is the one holding state.


Is that really true?  What about the Binding Cache?




To me, with this anycast approach, the anycast server is the mobile
node and the client is the correspondent node.  The mobile node
and the anycast server both hold state that identifies the home
address (anycast address) and the care-of address (unicast address).



In MIPv6 the binding cache entry is created only after the binding is
authenticated. The CN holds no state during the RR procedure. Only MN
does. Since only authenticated bindings go into the cache, you can't
flood it very easily.

However, you could flood the anycast server with RR state simply by
sending a lot of SYN packets with different forged source addresses.


Doesn't MIPv6 have the same problem with flooding an MN with bogus
data as a DoS attack?  Casting aside any issues with a binding cache,
where is the difference between the anycast server and a mobile node?

Won't flooding with SYN packets have the same affect on a mobile node?

Brian



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 PROTECTED]

Re: a few comments on anycast mechanisms

[Brian Haberman]

Mika Liljeberg wrote:

On Wed, 2003-01-29 at 13:23, Brian Haberman wrote:


Mika Liljeberg wrote:


I just spotted the following: the RR mechanism sends HoT to the anycast
address. How does that work? It might go to a completely different
server.


There is an assumption that there won't be a routing change on
the anycast address between the first TCP SYN and the HoT.  Given
the other problems a routing change would have, I feel it is a
reasonable trade-off.



I'm just wondering if this holds true for load balancers. For
transaction type application one might want to send each connection to a
different server.


The load balancer that I am aware of would actually use the source
address of the incoming packet as part of the algorithm to determine
which server to send the packet to.  So, for a short period of time,
packets with the anycast destination address and the same unicast
source address would be sent to the same server.

Now, I can't say that scenario is the common way to implement load
balancers.



Susceptibility to DoS attacks is another consideration that needs some
attention, I think. The RR mechanim in MIPv6 is designed to require no
state in CN, but in the anycast RR mechanisms the roles are reversed:
here the anycast server is the one holding state.


Is that really true?  What about the Binding Cache?

To me, with this anycast approach, the anycast server is the mobile
node and the client is the correspondent node.  The mobile node
and the anycast server both hold state that identifies the home
address (anycast address) and the care-of address (unicast address).

Regards,
Brian


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 PROTECTED]

Re: a few comments on anycast mechanisms

[Brian Haberman]

Mika Liljeberg wrote:

Hi Brian,

On Wed, 2003-01-29 at 00:03, Brian Haberman wrote:


The RR mechanism for anycast already requires the ability to use
the anycast address as a source address.  If we can get agreement
on lifting that restriction, I like the idea of keeping changes
out of TCP.



I just spotted the following: the RR mechanism sends HoT to the anycast
address. How does that work? It might go to a completely different
server.


There is an assumption that there won't be a routing change on
the anycast address between the first TCP SYN and the HoT.  Given
the other problems a routing change would have, I feel it is a
reasonable trade-off.

Brian


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 PROTECTED]

Re: a few comments on anycast mechanisms

[Brian Haberman]

Pekka Savola wrote:

On Mon, 27 Jan 2003, Brian Haberman wrote:


There are a _lot_ of issues there, especially if one anycast address can
have joins from across multiple routers.  Even more so if from across
multiple sites/AS's, or more specifically (with some terminology pixie
dust)  an IGP/iBGP area -- a region where propagating host routes is
acceptable.  But I'd recommend sticking to a site, the rest is way too
difficult for now.


Within a site it is no big deal.  Routers with attached anycast members
would inject a host-route for the anycast group into the IGP.



Well.. there are some issues, like propagation of  
validation information everywhere.

Sure.  I was referring more to the routing issue.  Within a site,
the scale of propogating the authentication information is much
smaller and better understood.


 

The big issue is with inter-site anycast.  A host route from a foreign
domain (i.e. not the prefix owner) could actually prevent anycast
traffic from reaching the owning domain unless explicit config allowed
for the "leaking" of the host route out of the home domain.



I see this as something that should be explicitly defined out-of-scope for 
these kind of anycast mechanisms.

So would I, except it is supported today in v4.


 

Thus by far the easiest way to enable anycast on hosts seems to be a
requirement for them to participate in a routing protocol.  Something like
BGP is good for this (not ideal: too much weight).  Simpler protocols can
of course also be used; the most important thing is to pick one which
allows your neighbor(s) to filter out any advertisements excluding the
anycast addresses(es) -- so that you can't hose the routing to other than
the anycast address(es) itself even in the worst case scenario.


One point of feedback we got from Itojun was that he preferred having
the hosts participate in the routing protocol (typically an IGP).  No
one else has really stated an opinion on this work.



I deem most IGP's insecure as the compromise of one node can do too much 
harm.  Therefore using iBGP w/route-reflection as an "IGP" with strict 
route-map's in the neighbors controlling the advertised information seems 
vastly preferable.
 

==> the problems with such a measure seems to be that:
1) MLD message does not signify other than link-local addresses AFAIR


Not sure what you mean.  Are you referring to the use of link-local
addresses in the IP header?  The group address within the MLD packet
can be of any scope.



Source addresses, yes.  Otherwise anyone on the link could join an anycast 
group.  Granted, without SEND, one could still do some hackery and capture 
the traffic anyway, but having some protection rather than nothing would 
be useful.

One possibility is an ICMP option that includes an authentication
key or some dependency on SEND.





2) some addresses are easily spoofed.

Of course, to be complete, some "reverse-path verification" for addresses, 
if routable unicast, would have to be done.


How so?  If a host joins an anycast group, it could be using any
unicast address.  What is the reverse-path check being done on?



The unicast address.  The point is to restrict those who can join to a
group to only a few, legal unicast addresses.  And that those MLD joins to
a group using unicast address X would actually require that X would be
routed to the interface/subnet from where the MLD join came from
(otherwise -> bombing/DoS attacks).

Or was there some misunderstanding..?


It sounds like you want to restrict anycast members to a single
link or that an anycast prefix has to be configured on multiple
interfaces around the network.





2) draft-haberman-ipv6-anycast-rr-00.txt (IPv6 Anycast Binding using 
Return Routability) -- Oct 2002.

==> Mobile IPv6 has progressed a bit and the draft needs a house-keeping 
update but the concept is clear.

Agreed.  I have not had time to update this work yet.



I wouldn't worry about that much yet..



- the high number of packets exchanged before commencing with real TCP 
traffic

What is high?  The figure on page 2/3 shows a total of seven messages
that have to be exchanged in order to establish a TCP session.  These
messages would be needed for MIPv6 as well.



Depends on the scope, of course.  To me, exchaning 7+3 messages just to
open a TCP session seems like a lot.  Especially when most, effective
anycast+TCP traffic should be short-lived (so routing changes do not
become a significant problem).

OTOH, anycast is currently applicable in site-internal traffic only where 
you can expect low network latency, ie no big problems except for the 
packet overhead.

So, for intra-site the extra messages are OK but not for inter-site
anycast?





3) that's it.  

My own, very raw idea for anycast + TCP: a new ICMP message, including the
seq number (or equivalent protocol-specific information)  of the
just-received TCP SYN, indicating the unicast

Re:a few comments on anycast mechanisms

[Brian Haberman]

I happened to read through a few older anycast-related drafts; a few
comments, to try to spark some discussion on how to go forward with
anycast.  Last, I bring up one idea how to possibly make TCP+anycast work,
in relatively simple terms.

1) draft-haberman-ipngwg-host-anycast-01.txt (Host-based Anycast using 
MLD) -- May 2002.

==> basically the MLD protocol is used to signal anycast joins/leaves.
However, critical part which seems to be missing here is "interactions of 
anycast-MLD with routing", as with multicast.

Correct.  At the time, the intent was to gauge interest in this approach
and then introduce guidelines on how routers should deal with the
information.



There are a _lot_ of issues there, especially if one anycast address can
have joins from across multiple routers.  Even more so if from across
multiple sites/AS's, or more specifically (with some terminology pixie
dust)  an IGP/iBGP area -- a region where propagating host routes is
acceptable.  But I'd recommend sticking to a site, the rest is way too
difficult for now.


Within a site it is no big deal.  Routers with attached anycast members
would inject a host-route for the anycast group into the IGP.

The big issue is with inter-site anycast.  A host route from a foreign
domain (i.e. not the prefix owner) could actually prevent anycast
traffic from reaching the owning domain unless explicit config allowed
for the "leaking" of the host route out of the home domain.



Thus by far the easiest way to enable anycast on hosts seems to be a
requirement for them to participate in a routing protocol.  Something like
BGP is good for this (not ideal: too much weight).  Simpler protocols can
of course also be used; the most important thing is to pick one which
allows your neighbor(s) to filter out any advertisements excluding the
anycast addresses(es) -- so that you can't hose the routing to other than
the anycast address(es) itself even in the worst case scenario.


One point of feedback we got from Itojun was that he preferred having
the hosts participate in the routing protocol (typically an IGP).  No
one else has really stated an opinion on this work.



A few points on security:

5. Security

   Unlike multicast, allowing nodes to join arbitrary anycast groups
   can result in denial-of-service attacks.  Whereas joining a
   multicast group does not prevent other nodes from seeing the same
   traffic, joining an anycast group can cause traffic previously seen
   by another node to be redirected to the newly joining node instead.

==> of course, this is more than just DoS.  This is packet capture and a 
man-in-the-middle attack too.

   To prevent such attacks, it is expected that routers will employ
   some filtering mechanism when receiving a Report message containing
   a non-multicast address.  For example, one policy might be to deny
   all anycast joins except those that match a configured list of
   (source address, anycast address) pairs.

Yes.



==> the problems with such a measure seems to be that:
 1) MLD message does not signify other than link-local addresses AFAIR


Not sure what you mean.  Are you referring to the use of link-local
addresses in the IP header?  The group address within the MLD packet
can be of any scope.


 2) some addresses are easily spoofed.

Of course, to be complete, some "reverse-path verification" for addresses, 
if routable unicast, would have to be done.


How so?  If a host joins an anycast group, it could be using any
unicast address.  What is the reverse-path check being done on?








2) draft-haberman-ipv6-anycast-rr-00.txt (IPv6 Anycast Binding using 
Return Routability) -- Oct 2002.

==> Mobile IPv6 has progressed a bit and the draft needs a house-keeping 
update but the concept is clear.

Agreed.  I have not had time to update this work yet.



However, I'm just not so sure that this is the right, even if seemingly 
sufficient, approach.  The main concerns from the top of the head seem to 
be:

 - the extent of MIPv6 support required to support this (I assume e.g. 
binding cache is needed)

Yes.



 - the high number of packets exchanged before commencing with real TCP 
traffic

What is high?  The figure on page 2/3 shows a total of seven messages
that have to be exchanged in order to establish a TCP session.  These
messages would be needed for MIPv6 as well.



 - the changes to TCP to run this operation at the reception of a specific
TCP SYN (perhaps this happens with MIPv6, but my impression has been that
in most cases, return routability is executed based on MN's own desire to
do send packets, not respond to some of them)


MIPv6 has to work in either direction.  The use of return routability
here is to signal the mapping of anycast<-->unicast.



 - the different model of address ownership model; this seem the most
important.  MIPv6 RR is used to prove that the MN has the right to use
certain care-of/home address.  These are network-topology -independent, in
a sense; a part of an autoc

Re: please reply I am posting 3rd time : Web Server addresses : Unicast, Multicast , Anycast

[Brian Haberman]

[EMAIL PROTECTED] wrote:

Yes that is what the spec says, but reality is always somewhat
different. There is no technical reason that an anycast address could
not be assigned to any group of hosts. The issue that must be dealt with



	there are technical reasons why anycast addresses can only be assigned
	to routers, and why anycast can be used with limited number of cases
	(like for instance it shouldn't be used as TCP endpoint address).
	draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt


Itojun's analysis draft does a good job of describing the issues today.
Of course, I hope draft-haberman-ipv6-anycast-rr-00.txt helps to
remove some of those issues.

Brian


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 PROTECTED]

Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt

[Brian Haberman]

Apologies, I missed that along the way.  That works for me.

Brian

[EMAIL PROTECTED] wrote:

Brian Haberman wrote:


I would like to see text in this document that explicitly states
that a flow is identified as .  That is override any
confusion caused by Appendix A of 2460 that says that a flow is
.



So the sentence (below) in the current section 2 ("IPv6 Flow Label Specification") is not explicit enough?

"IPv6 nodes forwarding or receiving a labeled IPv6 packet can use
the Flow Label and Source and Destination Address fields to classify
the packet to a certain flow."

	Jarno



-Original Message-----
From: ext Brian Haberman [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 11, 2003 11:41 PM
To: Thomas Narten
Cc: Brian E Carpenter; Rajahalme Jarno (NRC/Helsinki);
[EMAIL PROTECTED]
Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt




Thomas Narten wrote:


We may be more in agreement than appears. I agree that 

usage scenarios


should be left out. What I want to be sure about though is 

that router


implementors have a clear understanding of what they need to
implement, in order to be able to support flows once specific usages
are defined. (Or, please correct me if this is this not a 

goal here.)


I.e., folks doing hardware today want to know what they are supposed
to do with the Flow Label. They don't want to find themselves later
down the road saying "oops" our hardware can't support that 

because we


didn't know that's how flows were defined.

It may well be that all that needs to be said is that a flow is
defined by the three tuple, and that implementations need 

to classify


based on the tuple. What is done to packets that belong to a
particular flow is future work. But the definition of how the
classification is to be done seems important to nail down now. IMO,
the current wording about this could be more clear. But if hardware
folk feel like the current words are sufficiently clear on this, I'm
OK too.





Brian









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 PROTECTED]

Re: DAD scope ??

[Brian Haberman]

Ole Troan wrote:

Each ipv6-over-foo doc discusses modifications to ND,
if necessary, for the particular link technology.  For
example, Section 5 of RFC 2023 (IPv6 over PPP) mentions
that DAD is redundant and needn't be run.



my interpretation of IPv6 over PPP is different. DAD is redundant only
for the link-local address, but needs to be run for all other
addresses on the link.


The last sentence of the 2nd paragraph in Section 5 states:

 "Therefore it is recommended that for PPP links with
  the IPV6CP Interface-Token option enabled the default
  value of the DupAddrDetectTransmits autoconfiguration
  variable [3] be zero."

If DupAddrDetectTransmits is set to zero, then DAD is not run
on the interface since it is an interface variable.  The only
thing that implies that this only is for link-local addresses
is the title of the section.

Brian


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 PROTECTED]

Re: DAD scope ??

[Brian Haberman]

Fred L. Templin wrote:

Brian Haberman wrote:
 > Each ipv6-over-foo doc discusses modifications to ND,
 > if necessary, for the particular link technology.

Can you point me to any text in the core architecture
documents (e.g., RFCs 2461, 2462) that allow this and
can be used as normative reference?


The 2nd paragraph of the intro in 2461 begins with:

   Unless specified otherwise (in a document that covers
   operating IP over a particular link type) this document
   applies to all link types.

So, it looks like the override is in the link-specific
document and not in the core architecture documents.

Brian



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 PROTECTED]

Re: DAD scope ??

[Brian Haberman]

Each ipv6-over-foo doc discusses modifications to ND,
if necessary, for the particular link technology.  For
example, Section 5 of RFC 2023 (IPv6 over PPP) mentions
that DAD is redundant and needn't be run.

Regards,
Brian

Fred L. Templin wrote:

Margaret/others,

Margaret Wasserman wrote:


DAD is a link-local mechanism (uses link-local multicast
packets).  So, while it checks all addresses, it only
explicitly checks for duplicate addresses on the local link.



What about DAD for links that are unicast-only? Alternatives
I can imagine are:

 1. specify some sort of unicast mechanism for DAD
 2. perform some sort of multicast emulation (e.g., MARS)
 3. avoid DAD alltogether when one can assume that addresses
are uniquely assigned within the site

Thoughts?

Fred Templin
[EMAIL PROTECTED]



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 PROTECTED]






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 PROTECTED]

Re: Proposal for site-local clean-up

[Brian Haberman]

Margaret Wasserman wrote:




Current text:



Hi Brian,


>Site-local addresses are designed to be used for addressing 
inside of
>a site without the need for a global prefix.  Although a subnet ID
>may be up to 54-bits long, it is expected that globally-connected
>sites will use the same subnet IDs for site-local and global
>prefixes.

Proposed new text:

   Site-local addresses are designed to be used for addressing inside of
   a site which is not connected to the Internet and therefore does not
   need a global prefix.  They must not be used for a site that is 
connected
   to the Internet. Using site-local addresses, a subnet ID may be up to
   54-bits long, but it is recommended to use at most 16-bit subnet IDs,
   for convenience if the site is later connected to the Internet using a
   global prefix.


I would support this change.  However, I doubt that we will get
consensus to make this change before the addressing architecture
is issued as an RFC.  I guess we'll see how things develop in
Atlanta.


Alternatively, we could spend the next 5 years discussing the
unnecessary complexities of using site-locals on connected sites.



This is _exactly_ what I am hoping to avoid.

Let's limit site-locals to the well-understood case, and focus on
solving the real problems:

- Getting IPv6 finalized and ready for wide-scale deployment
- Multi-homing
- Renumbering
- Security model for shared IPv4/IPv6 networks


I agree with Brian and Margaret.

Brian



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 PROTECTED]

Re: I-D ACTION:draft-ietf-ipv6-prefix-delegation-requirement-00.txt

[Brian Haberman]

BELOEIL Luc FTRD/DMI/CAE wrote:

Does anyone think that a validity lifetime should be associated to the
prefix during prefix delegation?


Absolutely.



Indeed RAs sent on a link associate a valid lifetime and a preferred
lifetime to the advertised prefixes.


If your prefix is delegated to you, the delegating entity has to
provide a lifetime in order for the requestor to build meaningful
RAs.

Brian


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 PROTECTED]

Re: A few comments on Site-Local Useage

[Brian Haberman]

[EMAIL PROTECTED] wrote:

The original intent in the scoped addr arch was that the site-local
zone id would be indicate which interfaces are within a site.  The
filtering between sites is handled by the forwarding code.

Vendors that support these zone ids will have default values for the
zone ids.  If the vendors don't support the zone ids, the box will
be unable to act as a SBR unless the user builds the filters.



	"default value for zone ids"?  which document suggests that?
	i have never seen such docs.  draft-ietf-ipngwg-scoping-arch-04.txt
	talks about default zone id for global address (= 0), but is silent
	about site-locals to me.

itojun



From Section 6:

 An implementation should also support the concept of a "default" zone
 for each scope.  It is convenient to reserve the index value zero, at
 each scope, to mean "use the default zone".  Unlike other zone
 indices, the default ID does not contain any scope type, and the
 scope type is determined by the address by which the default ID was
 accompanied.  An implementation may additionally define a separate
 default zone for each scope type.  Those default indices can also be
 used as the zone qualifier for an address for which the node is
 attached to only one zone, e.g., when using global addresses.

Regards,
Brian


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 PROTECTED]

Re: A few comments on Site-Local Useage

[Brian Haberman]

Pekka Savola wrote:

On Thu, 7 Nov 2002, Keith Moore wrote:


What I meant to say that to implement site-locals properly in a router,
the vendor should not be OK to say "we support access-lists, you can use
them to configure site-local borders" or that "we have nice firewall
products, wanna buy one?".


I'm not sure about that.  Having routers try to automagically determine 
site boundaries sounds nice, unless there are cases where it will fail.
If the latter is true, then requiring explicit filter configuration seems
like the way to go. 


.. which brings me back to my original point that the spec text should be 
written in such a fashion that people don't expect the site-local filters 
to "just work", but that people need to do it themselves.

I'm not sure if folks really understand the security impleications (or 
lack thereof) when dealing with site-locals, and the spec doesn't make it 
any better.


The original intent in the scoped addr arch was that the site-local
zone id would be indicate which interfaces are within a site.  The
filtering between sites is handled by the forwarding code.

Vendors that support these zone ids will have default values for the
zone ids.  If the vendors don't support the zone ids, the box will
be unable to act as a SBR unless the user builds the filters.

Brian


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 PROTECTED]

Re: Limiting the Use of Site-Local

[Brian Haberman]

Richard Draves wrote:

[attacker] --- [internet]  [ISP] --- [customer w/ site locals]

Now the attacker can send packets with a fec0::/10 source 
address to the customer -- no one will block them unless 
they're explicitly configured as site borders -- before the 
customer itself.  And if the customer does not block them, 
we're in for very serious trouble.

That seemed to be what everyone except me read the ADDRARCH 
paragraph to imply.  I thought attackers first-hop router (or 
at the latest, attackers edge router) should block these 
packets automatically.


No. At least I read ADDRARCH as meaning that the routers between the
attacker and the customer would all be configured (one way or another -
either manually or because it's their default configuration) as site
boundaries, meaning they would filter the site-local packets.


Or if you follow Tony's model, each IGP/EGP boundary would filter
them.

Brian



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 PROTECTED]

Re: Default site-local behavior for routers

[Brian Haberman]

Margaret Wasserman wrote:




You're probably right.
On the other hand, as per Ole Troan's earlier email (which I agree
with), I don't think all router implementations should be required to
support multi-sites.



I think Ole's comments apply to specialized routers.  If you are
marketing a general purpose router, you almost have to put in
support since you don't know how or where they will be deployed.



Not necessarily.  Even if we go to the trouble of fully defining
how site-local address will work, it is still possible that the
market will decide not to support them.  If no one builds SBRs,
no one will have effective site borders.


I agree that could be a big issue.  We can't make vendors put
stuff in their boxes and we can't mandate how operators deploy
technology.  So do we only give them enough rope to make a
noose or do we give them enough to use constructively?




Are there any commercial routers today that include SBR support?


None that I know of.



Who has an implementation of an SBR that includes routing protocols?
Brian, I know you wrote one with RIPng.  Are there others?  I'd
be very interested in hearing about implementation experiences.


I started to do one for OSPF, but ran out of time.

Brian


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 PROTECTED]

Re: Default site-local behavior for routers

[Brian Haberman]

Margaret Wasserman wrote:


What doesn't really exist is the filtering of prefixes being put
into route exchange messages based on an arbitrary index (zone
id).

The other big issue is how the routing table(s) are built and
managed.  That can be a big hit on memory/storage space.



Brian, could you elaborate on these things?


Sure.  One of the issues that I had to deal with in the scoped
addr arch was how to represent the concept that multiple RIBs
are needed to support site-locals.  The conceptual model is that
you have a RIB for globals and RIB for each unique site-local
zone id in the box.

These tables can be implemented in several ways.  One way would
be to add a zone id entry to a monolithic RIB.  This means that
uniqueness is based on (prefix,zone id) rather than just on
prefix.  Another way would be to have separate RIBs (perhaps as
an array).  Then the lookup entails finding the table that
matches the incoming zone id and then the prefix in that table.

So, right there we have a more complex indexing structure, but
it is not too bad.  It looks similar to how some products do
VPN support.

Another hit is taken in each routing protocol.  When the protocol
builds its advertisement packet, it must do this selectively.
The zone id of the outgoing interface is retrieved and the routing
protocol then builds its advertisement using the global RIB and
the site-local RIB corresponding to the zone id.  This process has
to be done for each interface.

Does anyone want to hear the gory details on the forwarding plane
or is the explanation in the scoped addr arch enough?

Brian


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 PROTECTED]

Re: Limiting the Use of Site-Local

[Brian Haberman]

Margaret Wasserman wrote:




I don't see a performance drop in our implementation. an additional
table lookup is not needed for forwarding. you need to figure out the
scope of the DA of course, but that is needed for link-local/multicast
anyway.



The issue is that you also have to check the source address and drop
the packet if you would be crossing a scope boundary for the source
address...

I think that a lot of routers already (in IPv4) have the capability
of doing fast classification/filtering based on both source and
destination addresses (among other things), so I don't know how much
of a performance hit this will cause for a hardware-based routers.
And, as was already pointed out, you need to do it for link-local
addresses, anyway.


Right.  The data points I provided were for one possible implementation
of a RIB combined with a software-only router.  I can envision several
very useful optimizations to do SL routing/forwarding in hardware.

Brian


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 PROTECTED]

Re: Limiting the Use of Site-Local

[Brian Haberman]

Mark Smith wrote:


On Thu, 2002-10-31 at 13:13, Brian Haberman wrote:



Tony Hain wrote:


Mark Smith wrote:



...
On a related topic, if I was to stuff up my site local 
filters at the edge of my site, would my network then become 
part of my ISPs site local network ? 


You would both have to make an error to get the two IGPs tied together. 



In the proposed 
site-local models, are sites adjacent, or are they separated 
by segments that only have a global address assignments (eg 
the BGP AS model vs the OSPF area model) ?


I remember this discussion a few months back, but I don't remember the
conclusion. Maybe Ole does. 

The following is a proposal that was discussed amongst the
scoped addr arch authors and the ADs.  This model would address
the issue of having adjacent sites quite nicely.

   -- --
--|  |---|  |--
   -- --

<--site 1--> <-dummy site-> <-- site 2 -->

Brian



Thanks Brian, that make sense, and clears up my concerns about a single router being the site-local security device for both the provider and the customer.

Sorry if I'm asking dumb questions, I'm just thinking about how I might
use site local addressing if I was to build an Australia wide IPv6 based
enterprise network, interconnecting the main capital cities.

As an example, I can see three different ways I could site-local address
the 8 capital cities we have down here (for those who may not be aware,
we have something like at least 500 kilometers between capital cities
down here) :

* site-local boundary at the edge of each city. wan links between cities
would be treated as dummy sites as per your example above.

* delete the dummy sites in the previous model, and extend the
site-local boundary of one of the main sites out to the edge of all the
other sites eg the Sydney site local addressing would finish at the edge
of the Melbourne, Adelaide etc site local boundary

* with 54 bits of subnet address space available in the site-local
fec0::/10 address space, it would be very tempting to just treat the
whole of Australia as one big site, and avoid site boundary routing
configuration issues completely. 

Obviously my last two models don't really fit the idea that site-local
addressing is to cover a single geographical site.

Are there any documents / drafts / email threads that discuss various
possible site local addressing / boundary models I can have a read of ?

In your scenario, I would seriously consider Tony's proposal that
site borders be the same as IGP/EGP boundaries.  You could very easily
run each capital city as an IGP/site and interconnect them via BGP.
The BGP connectivity would be the "dummy site" described above.

Brian



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 PROTECTED]

Re: Limiting the Use of Site-Local

[Brian Haberman]

Bound, Jim wrote:

Tony,

What I want is a simple draft that says site-locals will not be
forwarded out of the site?
Brian Haberman et als work had that wordage but the other parts are far
from consensus.
What we could do is have Brian reduce to one draft working with Ole a
statement that this will not happen.  We need a bit more than trust me
it won't happen.


For those of you that have been around this topic for awhile, the
scoped addressing architecture document grew out of a draft I wrote
on the routing and forwarding aspects of SLs.

Is there consensus to have a standalone doc that talks about those
issues only?

Brian


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 PROTECTED]

Re: Limiting the Use of Site-Local

[Brian Haberman]

Ole Troan wrote:

[...]



The biggest hit is actually in the forwarding.  Each packet
gets at least one additional table lookup (for the incoming
zone id).  Then there are the checks to ensure that the source
address is valid (e.g. a site-local SA and global DA trying
to cross a site border).



you have to do the outgoing check for link-locals anyway.


Right, but the check for LL in the SA does not require
retrieving a zone id that has to be used in the forwarding
decision.





The extra cost?  Performance drops around 25-30% for a SBR
between 3 sites.  Of course, this was all software based,
but even a hardware-based solution will take the extra lookup
hits.



I don't see a performance drop in our implementation. an additional
table lookup is not needed for forwarding. you need to figure out the
scope of the DA of course, but that is needed for link-local/multicast
anyway.


What protocol is your implementation of SL routing utilizing?

How many sites are configured on the router?

Brian


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 PROTECTED]

Re: Default site-local behavior for routers

[Brian Haberman]

Mark Smith wrote:

On Thu, 2002-10-31 at 16:29, Keith Moore wrote:


however I'd be really surprised if SL filtering added to the
cost of a router.




You're probably right.

On the other hand, as per Ole Troan's earlier email (which I agree
with), I don't think all router implementations should be required to
support multi-sites. 

I think Ole's comments apply to specialized routers.  If you are
marketing a general purpose router, you almost have to put in
support since you don't know how or where they will be deployed.



As soon as a feature is optional, it can be charged more for, and in my
example, following the site-local philosophy, I would have to pay for
it.


That depends based on my comment above.



BTW, I'm not sure if you miss-phrased, but we are talking about full
multi-site forwarding support (ie zones etc), not just SL filtering.


I break the problem down into two parts, pieces that already exist
and pieces that really don't.

Some of the forwarding rules for site-locals look alot like the
ingress filtering that is done today to address spoofing.  So,
the machinery exists for that.  As Ole pointed out in another
message, there is some checking that is done for LL that can be
re-used for SLs.  The difference though is that the LL check
doesn't require retrieving an index in order to check.

What doesn't really exist is the filtering of prefixes being put
into route exchange messages based on an arbitrary index (zone
id).

The other big issue is how the routing table(s) are built and
managed.  That can be a big hit on memory/storage space.

Brian


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 PROTECTED]

Re: Default site-local behavior for routers

[Brian Haberman]

Tony,
 That is a reasonable approach and one that I could live
with.  It allows SLs to exist and control is based on tools
that are in wide use today.

Brian

Tony Hain wrote:

The whole discussion about lack of definition of site boundary is bogus,
and causing a large waste of energy. We don't tell people how to bound
areas in OSPF, yet we are expected to spell out the universal definition
of a site. To a first order, the concepts are exactly the same, how much
information is exposed across administrative borders. 

An organization should probably start with the assumption that a site
boundary is exactly congruent with an OSPF area, but they may choose to
restrict it further, or expand it when it makes sense for their network.
In any case, the site boundary should never be larger than the IGP
scope, so if we are going to talk about defaults, rather than assuming
every interface is in a different site, why not assume every EGP/IGP
boundary identifies a different site? If we can get past that, maybe we
can start talking about area boundaries as a reasonable default.

Tony



-Original Message-
From: [EMAIL PROTECTED] 
[mailto:owner-ipng@;sunroof.eng.sun.com] On Behalf Of Brian Haberman
Sent: Wednesday, October 30, 2002 10:46 AM
To: [EMAIL PROTECTED]
Subject: Default site-local behavior for routers


So, one of the items that Margaret suggested was some text in 
the node requirements doc or the scoped addr arch that states 
that nodes default to being in one site.

However, there has been some mention that people would prefer 
different behavior in routers.  That is, the stated desire 
was that, by default, each interface on a router be in its own site.

This suggestion leads to the model where hosts with multiple 
interfaces will assume that all its interfaces are in the 
same site (e.g. have the same site-local zone id) unless 
explicitly configured to have multiple sites.  While routers 
will default to having a unique site-local zone id for each 
interface (thus rendering SLs to link-local behavior) unless 
explicitly configured to have multiple interfaces in the same site.

This difference in behavior for hosts and routers leads to
some interesting issues.  One big one is how the site-local 
zone ids are setup and potentially changed when a host 
becomes a router or vice versa.

What are others' opinions on this issue?

Brian


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 PROTECTED]






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 PROTECTED]






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 PROTECTED]

Re: Limiting the Use of Site-Local

[Brian Haberman]

Ole Troan wrote:

A router might (and probably should) be hard-coded not to 
forward link-local packets, as there is no reason to ever 
forward them.

However, a router that might ever need have multiple 
interfaces in a single site can't be hard-coded not to 
forward site-locals. Whether or not they will be forwarded is 
the result of configuration.

Actually, a router can forward link-locals between interfaces on the
same link. In particular, a router can forward a packet with link-local
dest and/or source back out the interface from which it arrived (and
presumably generate a Redirect too).

If you are implementing link-locals properly, it's really very little
additional code to support site-locals. At least that's my experience.


	could you comment on routing code? (RIPng, OSPFv3)  i still think
	it's way too tough to support multi-sited node.



RIPng is relatively simple. link-state protocols require congruent
areas and sites. there are some open issues with regards to multicast
and PIM I believe. routing protocol support is required in any case
for VPNs.


The actual routing protocol changes in RIPng is dependent on
how you structure your RIBs.  I hacked RIPng to make an SBR
using a monolithic RIB with an additional index (the zone id).
It was an additional 800-900 lines of code to deal with
figuring out which RIB entries needed to be advertised on each
interface.

Then there are the changes to configure and maintain the zone
IDs.

The biggest hit is actually in the forwarding.  Each packet
gets at least one additional table lookup (for the incoming
zone id).  Then there are the checks to ensure that the source
address is valid (e.g. a site-local SA and global DA trying
to cross a site border).

The extra cost?  Performance drops around 25-30% for a SBR
between 3 sites.  Of course, this was all software based,
but even a hardware-based solution will take the extra lookup
hits.

Brian


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 PROTECTED]

Re: Default site-local behavior for routers

[Brian Haberman]

For the record, my opinion follows Ole's comments.

Brian

Rob Austein wrote:

What Ole said.

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 PROTECTED]






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 PROTECTED]

Re: Limiting the Use of Site-Local

[Brian Haberman]

Tony Hain wrote:

Mark Smith wrote:


...
On a related topic, if I was to stuff up my site local 
filters at the edge of my site, would my network then become 
part of my ISPs site local network ? 


You would both have to make an error to get the two IGPs tied together. 


In the proposed 
site-local models, are sites adjacent, or are they separated 
by segments that only have a global address assignments (eg 
the BGP AS model vs the OSPF area model) ?


I remember this discussion a few months back, but I don't remember the
conclusion. Maybe Ole does. 

The following is a proposal that was discussed amongst the
scoped addr arch authors and the ADs.  This model would address
the issue of having adjacent sites quite nicely.

   -- --
--|  |---|  |--
   -- --

<--site 1--> <-dummy site-> <-- site 2 -->

Brian


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 PROTECTED]

Re: Limiting the Use of Site-Local

[Brian Haberman]

Jun-ichiro itojun Hagino wrote:


	could you comment on routing code? (RIPng, OSPFv3)  i still think
	it's way too tough to support multi-sited node.


Not that the chairs have finalized the agenda, but I am planning
on presenting what it took me to get a site-border router coded
and running.  If you want to request a certain level of detail,
let me know.

Brian


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 PROTECTED]

Default site-local behavior for routers

[Brian Haberman]

So, one of the items that Margaret suggested was some text in
the node requirements doc or the scoped addr arch that states
that nodes default to being in one site.

However, there has been some mention that people would prefer
different behavior in routers.  That is, the stated desire
was that, by default, each interface on a router be in its own
site.

This suggestion leads to the model where hosts with multiple
interfaces will assume that all its interfaces are in the
same site (e.g. have the same site-local zone id) unless
explicitly configured to have multiple sites.  While routers
will default to having a unique site-local zone id for each
interface (thus rendering SLs to link-local behavior) unless
explicitly configured to have multiple interfaces in the
same site.

This difference in behavior for hosts and routers leads to
some interesting issues.  One big one is how the site-local
zone ids are setup and potentially changed when a host
becomes a router or vice versa.

What are others' opinions on this issue?

Brian


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 PROTECTED]

Re: Forwarding packets with site-local source [Re: Choices to goforward with SL]

[Brian Haberman]

Rich,

Richard Draves wrote:

Some read it (many):

"if I configure a site here, I must also block site-locals 
from spreading 
out or false site-locals coming in"

Some others read it:

"if I use site-locals here, my upstream router will block 
the site-local 
addresses from spreading out and prevent anyone from spoofing 
site-locals 
to my site"

The latter is how I read it must be implemented -- and 
reading Microsoft's implementation and the reason they're 
using SL *strongly* suggests they 
also have read it that way.  There are very probably many others.


No, I think you're the only person reading it the latter way.

My expectation is that routers will need to be configured to understand
site boundaries. A conservative position is that routers by default
should regard their interfaces as belonging to different sites, unless
they are configured to be in the same site. Or perhaps other aspects of
the router's configuration (eg the network prefixes assigned to
different interfaces, or the routing protocols in use) could be used to
default the site configuration.


I would be a little concerned with allowing a border configuration
to be controlled by a routing protocol.  A routing flap could do
all sorts of nasty things in that situation.

My take is that the two possible router configs for site locals is

 1.  All interfaces are in the same site
 2.  All interfaces are in unique sites

Margaret's proposal that the default behavior is a node's
interfaces are in 1 site results in case 1.  For a router, a
safer config may be 2.  That would strictly limit the outward
flow of site local addresses.

Brian


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 PROTECTED]

Re: Forwarding packets with site-local source [Re: Choices to goforward with SL]

[Brian Haberman]

Mark,

[EMAIL PROTECTED] wrote:

Pekka Savola wrote:


On Tue, 29 Oct 2002, Brian Haberman wrote:



Note that KAME only supports this through manual configuration (and a 
fix) -- clarified in off-the-list discussion.

To be compliant with the paragraph:

  Routers must not forward any packets with site-local source or
  destination addresses outside of the site.

Note: it does not say 'packets from the site' (implying configuration of
the site) but 'with site-local source'.  That strongly implies explicit
configuration will not satisfy.

I don't read it that way at all.  I interpret that to mean, if the
router is configured as a site-border router it must not forward those
packets out of the site.



That kind of interpretation is easy (== activation logic in the 
implementation is simple) , but really, totally useless I believe.

That depends on the model you believe.  If we take Margaret's proposal
that, by default, a node is in one site (you treat SLs as globals) then
explicit config is needed to have a border router.  In this scenario,
the site-local zone ids are all the same.

The other case is where each interface is in different site (that makes
SLs equivalent to link-locals) and the site-local zone ids are all
unique.



	There is also the case where the number of sites < number of interfaces
	and number of sites != 1.

	e.g.
		interfaces 1 and 4 are in site 1
		interfaces 2 and 5 are in site 2
		interface 3 is in site 3
	
	You have to allow SL traffic between 1 and 4 also between
	2 and 5 but not between any other combination of interfaces.


I agree that such a configuration should be allowed.  My example
was to point out the two possible default behaviors that could
occur with no admin configuration.

Brian



	Mark



The promise of using site-locals is that they will not propagate globally.

Routers must make sure they don't do that, even without being configured 
as site-border routers.

That would require routers to always act as a site border router.



If this wasn't true, nobody should be able to use site-locals even without 
relatively clean conscience, as nobody could be sure there _is_ a router 
that's blocking illegally-sourced site-locals from coming to my site or 
vice versa.

The paragraph requires clarification for sure.

How about removing it?





The behavior is as defined in Section 5 of the scoped addr arch which
is all interfaces are in the same site, unless explicitly configured
by an administrator.



Scoped arch draft is irrelevant from the perspective of addrarch 
(independence) IMO.

What I meant is that any discussion similar to that paragraph should
be in the scoped addr arch.







1) node just blindly configures fec0::1 and starts sending traffic using 
it, testing how far it will go. 

A valid scenario here could be that site-locals would be used inside one
link only -- no config at all in the router -- but the route must disallow
propagation of site-locals through default route if something fails.

That does not follow from the discussion in scoped addr arch.  Of
course, this should be clarified in addr arch when we decide on the
SL content of that document.



Better: _addrarch_ shouldn't say anything at all like that because we 
don't know how to do it (or can't write it down).

Agreed.





You may ask: how is this possible?  we don't have any site-border 
discovery mechanisms?

I say: exactly, that's why the paragraph is so ridiculous!

The only easy and compliant implementation I could think of would be 
discarding all site-locals unless some links are explicitly configured to 
be part of a site.

From the discussion I have read, it seems that it would be more that
we are assuming that all interfaces are in the same site unless
explicitly configured.



The risk of site-local leakage is _way_ too big that way.


My statement is based on the proposal that site-locals be restricted
to disconnected networks.

Brian



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 PROTECTED]



--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]

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 PROTECTED]






IETF 

Re: Forwarding packets with site-local source [Re: Choices to goforward with SL]

[Brian Haberman]

Pekka Savola wrote:

On Tue, 29 Oct 2002, Brian Haberman wrote:


Note that KAME only supports this through manual configuration (and a 
fix) -- clarified in off-the-list discussion.

To be compliant with the paragraph:

   Routers must not forward any packets with site-local source or
   destination addresses outside of the site.

Note: it does not say 'packets from the site' (implying configuration of
the site) but 'with site-local source'.  That strongly implies explicit
configuration will not satisfy.

I don't read it that way at all.  I interpret that to mean, if the
router is configured as a site-border router it must not forward those
packets out of the site.



That kind of interpretation is easy (== activation logic in the 
implementation is simple) , but really, totally useless I believe.

That depends on the model you believe.  If we take Margaret's proposal
that, by default, a node is in one site (you treat SLs as globals) then
explicit config is needed to have a border router.  In this scenario,
the site-local zone ids are all the same.

The other case is where each interface is in different site (that makes
SLs equivalent to link-locals) and the site-local zone ids are all
unique.



The promise of using site-locals is that they will not propagate globally.

Routers must make sure they don't do that, even without being configured 
as site-border routers.

That would require routers to always act as a site border router.



If this wasn't true, nobody should be able to use site-locals even without 
relatively clean conscience, as nobody could be sure there _is_ a router 
that's blocking illegally-sourced site-locals from coming to my site or 
vice versa.

The paragraph requires clarification for sure.

How about removing it?





The behavior is as defined in Section 5 of the scoped addr arch which
is all interfaces are in the same site, unless explicitly configured
by an administrator.



Scoped arch draft is irrelevant from the perspective of addrarch 
(independence) IMO.

What I meant is that any discussion similar to that paragraph should
be in the scoped addr arch.


 

1) node just blindly configures fec0::1 and starts sending traffic using 
it, testing how far it will go. 

A valid scenario here could be that site-locals would be used inside one
link only -- no config at all in the router -- but the route must disallow
propagation of site-locals through default route if something fails.

That does not follow from the discussion in scoped addr arch.  Of
course, this should be clarified in addr arch when we decide on the
SL content of that document.



Better: _addrarch_ shouldn't say anything at all like that because we 
don't know how to do it (or can't write it down).

Agreed.





You may ask: how is this possible?  we don't have any site-border 
discovery mechanisms?

I say: exactly, that's why the paragraph is so ridiculous!

The only easy and compliant implementation I could think of would be 
discarding all site-locals unless some links are explicitly configured to 
be part of a site.

From the discussion I have read, it seems that it would be more that
we are assuming that all interfaces are in the same site unless
explicitly configured.



The risk of site-local leakage is _way_ too big that way.


My statement is based on the proposal that site-locals be restricted
to disconnected networks.

Brian



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 PROTECTED]

Re: Limiting the Use of Site-Local

[Brian Haberman]

Keith Moore wrote:

One advantage of having scoped addresses defined in the IPv6
architecture from the start is that applications can know not to pass
them outside of their scope. 

I have heard this stated by several people before and I am not sure
how apps are supposed to know this.  Especially since it was stated
that each nodes view of what is a site is independent of other nodes.




NO.

1. applications don't know where their scope ends.


Are people assuming that a functionality similar to MZAP (RFC 2776)
is going to be used to advertise site information?

Brian


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 PROTECTED]

Re: Forwarding packets with site-local source [Re: Choices to goforward with SL]

[Brian Haberman]

Pekka,

Pekka Savola wrote:

On Tue, 29 Oct 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote:


(Note: this message is not directly related to the main point of this
thread.)



On Tue, 29 Oct 2002 08:51:12 +0200 (EET), 
Pekka Savola <[EMAIL PROTECTED]> said:


I'm not even sure if we could get addrarch to draft standard, have folks 
implemented these two:


--8<--
  Routers must not forward any packets with site-local source or
  destination addresses outside of the site.
--8<--



None of the implementations I use certainly haven't, and this has been 
around for a time now, even since RFC1884..

KAME can do this.


I have implemented it as well.




Note that KAME only supports this through manual configuration (and a 
fix) -- clarified in off-the-list discussion.

To be compliant with the paragraph:

Routers must not forward any packets with site-local source or
destination addresses outside of the site.

Note: it does not say 'packets from the site' (implying configuration of
the site) but 'with site-local source'.  That strongly implies explicit
configuration will not satisfy.

I don't read it that way at all.  I interpret that to mean, if the
router is configured as a site-border router it must not forward those
packets out of the site.

The behavior is as defined in Section 5 of the scoped addr arch which
is all interfaces are in the same site, unless explicitly configured
by an administrator.



I expect an implementation must automatically, without any configuration, 
drop e.g. packets received under the following steps:

1) a router is configured to advertise a site-local prefix
2) a node configures a site-local address and starts sending out traffic
3) router drops it or forwards it (using some logic).

Or even:

1) node just blindly configures fec0::1 and starts sending traffic using 
it, testing how far it will go. 

A valid scenario here could be that site-locals would be used inside one
link only -- no config at all in the router -- but the route must disallow
propagation of site-locals through default route if something fails.

That does not follow from the discussion in scoped addr arch.  Of
course, this should be clarified in addr arch when we decide on the
SL content of that document.




You may ask: how is this possible?  we don't have any site-border 
discovery mechanisms?

I say: exactly, that's why the paragraph is so ridiculous!

The only easy and compliant implementation I could think of would be 
discarding all site-locals unless some links are explicitly configured to 
be part of a site.

From the discussion I have read, it seems that it would be more that
we are assuming that all interfaces are in the same site unless
explicitly configured.

Brian


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 PROTECTED]

Re: Limiting the Use of Site-Local

[Brian Haberman]

Hesham Soliman (EAB) wrote:

  > >   > > => I certainly didn't mean to suggest that the IETF
  > >   > > has an enforcement authority. I meant that this words
  > >   > > are used in cases where: if not followed, the protocol
  > >   > > will break. Therefore people generally follow them.
  > >   >
  > >   > if SLs are used in an environment where applications 
  > communicate
  > >   
  > ^
  > >   > across scope boundaries,
  > > ^^^
  > > => In other words, be careful how you use it. That's not
  > > a reason to deprecate the use of site-locals altogether.
  > 
  > Their use should be confined to completely isolated 
  > networks so that 
  > they don't break applications.   And yet this same 
  > constraint was imposed
  > on RFC 1918 and it didn't stop RFC 1918 addresses from 
  > being misused.
  > So yes, I think there's a compelling case for deprecating 
  > SLs entirely.
  > But I'd be happy to hear of a way to impose a 1918-like restriction
  > that would actually work this time around.

=> It has a better chance of working this time because:
- No one expects addresses to become a scarce resource in our
lifetime anyway

- I haven't seen any plans by ISPs to charge based on 
the number of addresses. 

So, I don't think it's quite the same problem as with
RFC1918.

I agree that scarcity is not the issue.  Rather, the end user
sees it as simpler to slap a NAT in the network and connect
rather than go through and renumber the network.

Brian



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 PROTECTED]

Re: Node Requirements Issue 3

[Brian Haberman]

Margaret,

Margaret Wasserman wrote:

At 12:17 PM 10/24/02, Margaret Wasserman wrote:


I think that we should keep site-local addresses in the
addressing architecture, but limit their use to non-globally-
connected IPv6 networks.



Some folks have pointed out that it might have been helpful if
I had explained my reasoning...

The addressing architecture currently defines a set of addresses
that are allocated for use as "site-local unicast addresses", but
it does not discuss the details of when or how those addresses can
or should be used.


This is fine with me.



The scoped addressing architecture document defines how site-local
unicast addresses (and other scoped addresses) will be used, and
defines node behaviour related to these addresses.  I am suggesting
that we should consider placing some restrictions on the _use_
of site-local addresses in the scoped addressing architecture
document.


I agree.



However, it is imperative that the site-local address allocation
remain in the addressing architecture, even if we do decide that
the use of these addresses should be restricted (or even forbidden).
The allocation has been there for several years, and there are some
implementations that recognize these addresses.


Yes.



I also believe that it is apporpriate for the node requirements
document to indicate the minimal acceptable support that a node
should have for site-local unicast addressing.

In my opinion, we should limit the use of unicast site-local
addresses to non-globally connected sites, and have the following
requirements for IPv6 nodes:

- Hosts do not have to be aware of site-local addresses
at all (treat them just like globals).
- Routers do not have to be aware of site-local
addresses at all (treat them just like globals).


May I suggest that this behavior MUST be the default?  That way,
an administrator has to make a conscious decision to enable the
multi-sited feature.



I do understand that, even if we do make this restriction, there may
be some people in the world who will later insist on using site-local
addresses (or other allocated private addresses) to build
a private address space within a globally connected IPv6 network.
I also understand that those people may build a kludge tower to
support this, similar to the IPv4 kludge tower needed to support
NAT, but with the added twist that a single node may have both
private and global addresses (yum!).  However, I don't think that
the IPv6 WG should go down the rat-hole of documenting that kludge
tower...


Completely agree.



Instead, I think that we should advocate a position where all
nodes on globally attached networks have global addresses, and
site-local addresses are only used on non-globally connected
networks.  This would work with the currently documented IPv6
routing protocols, would provide the easiest IPv4->IPv6 transition
for applications, and would not require changes to DNS.  This also
has the advantage of limiting the problem that the IPv6 WG is trying
to solve, which should allow us to finish up the base IPv6 documents
and confidently deploy IPv6.


Good.



In my opinion, IPv6 does not require support for private
site-local unicast address spaces to be successful.  The major
benefits of IPv6 are a larger address space (which should eliminate
some motivations for using private address spaces) and host
autoconfiguration, and I think that the world is already preparing
to deploy IPv6 based on those current advantages.


I would like to re-iterate that v6 does not need site-local
addresses to be successful.  To me, the benefit does not come
close to outweighing the cost.



I _would_ support an effort to start a separate IRTF or IETF WG
to explore whether we can build an architecturally sound model for
private and global addresses to co-exist on the same network
and in the same nodes, but I would prefer not to invent that
model in the IPv6 WG and build it into the core of IPv6.


Sounds reasonable to me.



This is my personal opinion, not a directive from the chairs or
anything like that.


So, the synopsis is:

 1. FE80::/10 allocation stays in addr arch
 2. Text is added to the node reqs specifying single-site
 behavior as the default
 3. Text is added to the scoped addr arch to clearly define
the use case for scoped addresses

What about text clarifying the issue with multi-link subnets in
addr arch?

Brian


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 PROTECTED]

Re: Node Requirements Issue 3

[Brian Haberman]

Rich,
 Just for my edification:

 1. Who else has site-local support?

 2. Can you describe the operational deployments?

 3. What applications?

Thanks,
Brian

Richard Draves wrote:

This is craziness. We (I don't mean just MS) have shipping
implementations that support site-locals. We have operational
deployments using site-locals. We have applications that work just fine
with site-locals.

Rich


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 PROTECTED]






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 PROTECTED]

Re: Node Requirements Issue 3

[Brian Haberman]

Hi Roy,

Roy Brabson wrote:

This is craziness. We (I don't mean just MS) have shipping
implementations that support site-locals. We have operational
deployments using site-locals. We have applications that work just fine
with site-locals.



Could you (or someone else who has this working) publish an ID which 
describes how site-locals work?  I've seen many postings on various 
aspects of site-locals which do not work as currently defined, from DNS to 
routing to applications using site-locals in referrals.  There have been 
some proposals on how to address some of these issues, such as updates to 
dynamic routing protocols, but others (like DNS) don't seem to have any 
agreed upon solutions in multi-sited configurations and, arguably in the 
case of DNS, single-sited configurations.  Without standards, or at least 
standards-track IDs, its hard to see how site-locals can be viewed as 
useful beyond a single-site configuration, with anything beyond that being 
experimental and/or proprietary.

I have been meaning to write a draft on what I had to do to routing
and forwarding in order to get site-border functionality.  But, I don't
think that would address the bigger issues that have been discussed.
The routing and forwarding is complex, but it doesn't compare to some
of the other issues.

If anyone wants to hear about what it took to get RIPng to do site
border functionality, let me know and I will put something together.

Brian


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 PROTECTED]

Re: Node Requirements - issue 1

[Brian Haberman]

[EMAIL PROTECTED] wrote:

Hi Pekka,



I might a bit hesitant to add a MUST for MLDv2, as MLDv2 is 
new and much more code than MLDv1; rather like MUST for MLDv1 
as above, SHOULD for overall MLDv2.


I tend to agree, but I am not an expert in MLDv2, so I just 
want to know what will break if nodes don't impelement it.

Nothing will break.  New implementations that support MLDv2
can, if necessary, fall back to MLDv1 in the presence of
older versions.

I don't think code size should even be considered.  MLDv2
is a more robust protocol that allows for newer functionality,
like SSM.

Another point to consider is that RFC 2710 (MLDv1) will not
progress beyond Proposed Standard.

If the point of this document is to tell new implementors what
they should implement, then my feeiling is that the group
management protocol should be MLDv2.

Regards,
Brian


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 PROTECTED]

Re: Node Requirements status

[Brian Haberman]

Hi John,

[EMAIL PROTECTED] wrote:

Hi all,

The nodes requirement draft has a number of issus to be addressed, so I would
like to send a list of open issues & then send possible resolutions to the
issues in seperate mails.

	1) What is the correct level of support for MLD?  Should MLDv2 be supported as well?


MLDv2 has been submitted to the IESG.  Given that, MLDv2 is the
correct level of support.


	2) MIPv6 draft suggestions for Node requirements be accepted?
	3) How to suppor Site Local Addresses.


A node is only required to support being in 1 site.  The issues with
multi-sited nodes is too complex to make a mandatory feature.  By
supporting 1 site, the node can treat the site local addresses as
globals.


	4) Some issues that have come-up during Address Scoping discussion.
	5) Anything needed to be captured Address Architecture document implications
	6) Default Address Selection level of support.
	7) Sub-IP layers (IP over Foo) - should all be included, or just one or two?


Given that new layer-2 technologies will appear and future docs may/will
define how IPv6 runs over those layers, I would suggest using generic
text that says that if a vendor wants to support IPv6 over a particular
L2, then they must implement the IPv6-over-foo spec for that L2.  Then
I would give a few examples (IPv6-over-ethernet, etc.).


	8) Support for DNS (is it a MUST)?  Support for DNS discovery / DHCP?
	9) Are Transition mechanisms mandatory; is support for IPv4 mandatory?
	10) What level of detail is needed for MIBs in the document?


It would be nice if the node requirements pointed out the version
independent MIBs that are in progress.  But, I don't think we want to
hold up this spec on those specs.


	11) Requirements language (MUST/SHOULD/MAY, etc.) needs discussion.

So, I will try to send out today at least suggestions on a number of the points,
but please speak up as to what you would like to see the addressed in the document.


It would be nice to get some more details on some of these open issues

Regards,
Brian


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 PROTECTED]

Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt

[Brian Haberman]

Keith,

Keith Moore wrote:
>> My point is that I believe that a clean separation should be made
>>between global addresses and scoped addresses.  We fully understand
>>how globals and link-locals work.  All the others are still being
>>hashed out.  If we make this break, the address architecture can
>>move along the standards track.  The (great amount of) additional
>>work that needs to be done on scoped addresses can be carried out
>>under the scoped address architecture.
> 
> 
> actually I'd claim that we don't really understand how link-locals
> work, at least not from the applications viewpoint.  but I enthusiastically 
> support the idea of separating the work on globals from the work
> on scoped addresses. 

I believe we do have a good understanding on how link-locals
work with utility protocols (ICMP, ND, MLD, routing protocols).
That is why the LL are needed in the base addressing architecture.
As for LL and user apps, I can't speak authoratively on the subject.

Brian


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 PROTECTED]

Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt

[Brian Haberman]

Bob,
I went back and re-read the thread you mention below.  There is
absolutely no reason why discussion of site-locals couldn't be moved
to the scoped addressing architecture doc.  It wouldn't affect the
text needed in the Node Requirements draft and it would put all the
scoped addressing discussion in one place.

Regards,
Brian

Bob Hinden wrote:
> 
> Brian,
> 
> I think this goes to far.  We have recently had a long discussion on the
> list regarding unicast site-local that concluded with keeping the
> definition of unicast site-local addresses in the document (see my email on
> 21 Jun 2002, titled "Consensus on Site-Local Discussion").  Part of that
> was that we would add text to the Node Requirements document that nodes are
> only required to implement the rules specified in the default address
> selection document (now a Proposed Standard) and that there be no
> requirement that a node must be able to be part of more than one zone.
> 
> Bob
> 
> >I would go a step further.  Since almost no one has implemented the
> >routing/forwarding of scoped addresses (multicast & unicast site
> >locals), I recommend:
> >
> >  1. Move all discussion of multicast scopes out of the addr-arch
> > and into the scoped addr-arch doc
> >  2. Move all text on site-local unicasts out of the addr-arch
> > doc and into the scoped addr-arch doc
> >  3. Add explicit text to the scoped addr-arch doc to define
> > how/when/where these scopes should be used
> >
> >This would allow the addr-arch doc to progress to DS without being
> >hung up on text involving scoped addresses but still describing the
> >pieces that we know work (e.g. global and link-local).  It would also
> >make a clean delineation between global and scoped addresses.
> >
> >The scoped addr-arch doc can then be the home for future work on
> >scoped addresses.
> >
> >My reasoning is based on actually having implemented scoped routing
> >and forwarding.  It is not trivial or for the weak of heart.

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 PROTECTED]

Re: IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver"

[Brian Haberman]

Rob Austein wrote:
> 
> At Fri, 11 Oct 2002 14:13:45 -0700, Bob Hinden wrote:
> >
> > This is a IPv6 working group last call for comments on advancing the
> > following document as a Proposed Standard:
> >
> > Title: Well known site local unicast addresses for DNS resolver
> 
> I have written about this document at some length before, so I will
> summarize rather than repeating the entire thing.  In brief:
> 
> My main objection was and remains that this mechanism, if used, moves
> state away from the endpoints and into the network in a way that
> cripples the resolver's ability to keep track of which of the name
> servers it is using are performing properly, since the binding between
> any particular well-known-address and the name server behind it might
> change at any time and since there is no mechanism by which the
> resolver can find out that such a change has taken place.

What if we applied the principles that Erik and I propose in
draft-haberman-ipv6-anycast-rr-00.txt?  That would allow for the
resolver to bind an address for the server.

Brian

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 PROTECTED]

Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt

[Brian Haberman]

Bob,
 What about all the multicast scopes?

 And will the new text in the Node Requirements document apply to
routers?  That is where many of the issues arise with site-locals.

 I won't even bring up the issues with DNS and site-locals.

 My point is that I believe that a clean separation should be made
between global addresses and scoped addresses.  We fully understand
how globals and link-locals work.  All the others are still being
hashed out.  If we make this break, the address architecture can
move along the standards track.  The (great amount of) additional
work that needs to be done on scoped addresses can be carried out
under the scoped address architecture.

Brian

Bob Hinden wrote:
> 
> Brian,
> 
> I think this goes to far.  We have recently had a long discussion on the
> list regarding unicast site-local that concluded with keeping the
> definition of unicast site-local addresses in the document (see my email on
> 21 Jun 2002, titled "Consensus on Site-Local Discussion").  Part of that
> was that we would add text to the Node Requirements document that nodes are
> only required to implement the rules specified in the default address
> selection document (now a Proposed Standard) and that there be no
> requirement that a node must be able to be part of more than one zone.
> 
> Bob
> 
> >I would go a step further.  Since almost no one has implemented the
> >routing/forwarding of scoped addresses (multicast & unicast site
> >locals), I recommend:
> >
> >  1. Move all discussion of multicast scopes out of the addr-arch
> > and into the scoped addr-arch doc
> >  2. Move all text on site-local unicasts out of the addr-arch
> > doc and into the scoped addr-arch doc
> >  3. Add explicit text to the scoped addr-arch doc to define
> > how/when/where these scopes should be used
> >
> >This would allow the addr-arch doc to progress to DS without being
> >hung up on text involving scoped addresses but still describing the
> >pieces that we know work (e.g. global and link-local).  It would also
> >make a clean delineation between global and scoped addresses.
> >
> >The scoped addr-arch doc can then be the home for future work on
> >scoped addresses.
> >
> >My reasoning is based on actually having implemented scoped routing
> >and forwarding.  It is not trivial or for the weak of heart.

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 PROTECTED]

Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt

[Brian Haberman]

Margaret Wasserman wrote:
> 
> At 02:25 PM 10/10/02, Robert Elz wrote:
> 
>> So would I.   The change I would make is to delete all references
>> of subnet-local from the addr-arch doc, and simply leave those values
>> as "to be defined" and then define them in the scoping-arch doc.
> 
> 
> This seems reasonable to me.
> 
> It moves this issue out of the IPv6 addr arch, allowing that document
> to move ahead, and let's us work out the details in the scoped addr
> arch and/or the multi-link subnets doc.
> 
> Good idea, Robert.
> 
> What do other folks think?

I would go a step further.  Since almost no one has implemented the
routing/forwarding of scoped addresses (multicast & unicast site
locals), I recommend:

  1. Move all discussion of multicast scopes out of the addr-arch
 and into the scoped addr-arch doc
  2. Move all text on site-local unicasts out of the addr-arch
 doc and into the scoped addr-arch doc
  3. Add explicit text to the scoped addr-arch doc to define
 how/when/where these scopes should be used

This would allow the addr-arch doc to progress to DS without being
hung up on text involving scoped addresses but still describing the
pieces that we know work (e.g. global and link-local).  It would also
make a clean delineation between global and scoped addresses.

The scoped addr-arch doc can then be the home for future work on
scoped addresses.

My reasoning is based on actually having implemented scoped routing
and forwarding.  It is not trivial or for the weak of heart.

Brian


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 PROTECTED]

Re: Implementation worries about default address selection

[Brian Haberman]

Pekka Savola wrote:
> On Wed, 9 Oct 2002, Erik Nordmark wrote:

[snip]

>>I'm not worried about this. We have exactly the same issue for routing table
>>lookup in hosts and routers; there is no specification that states how
>>to implement caching schemes.
> 
> 
> We haven't really specified the source address selection like this for 
> IPv4 either, I believe.  Have I missed something?
> 
> Routing table lookup is very simple compared to this I think.

Have you looked at the routing/forwarding sections of the scoped
addressing architecture?  It used to be simple.

Brian




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 PROTECTED]

Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt

[Brian Haberman]

Dave Thaler wrote:
> 
> > -Original Message-
> > From: Brian Haberman [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, October 09, 2002 1:48 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: IPv6 subnet-local addresses and
> draft-ietf-ipngwg-addr-arch-
> > v3-10.txt
> >
> > Dave Thaler wrote:
> > >>From: Brian Haberman [mailto:[EMAIL PROTECTED]]
> > >>
> > >>>>The more I think about it, the more I realize that "automagically"
> > >>>>creating the subnet-local scope zone id isn't going to work.
> > >>>>Especially with multiple prefixes per interface.
> > >>>
> > >
> > > Why not?  Can you elaborate?
> > > Shouldn't it always be true that if any two interfaces have the
> > > same (non-link-local) subnet prefix, then their subnet-local
> > > zone id MUST be the same?
> >
> > What happens to the zone ids when:
> >
> >   1. Interface 1 has prefix1 and prefix2
> >   2. Interface 2 has prefix1 and prefix3
> >   3. Interface 3 has prefix2 and prefix4
> 
> According to the default rule, all three are in the
> same subnet-local zone.  You've just chosen for some
> reason not to advertise some prefixes on some links.
> Personally, I'd put this in the category of "don't do that",
> just like I wouldn't recommend using using different subnet
> ids for different prefixes on the same link.

Why are some prefixes not advertised?

What happens if prefix3 is FE80:1:2:3::/64 and Interfaces 2&3 have
different site-local zone ids?  Then obviously you can't make all
three interfaces be in the same subnet-local zone id.

Brian

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 PROTECTED]

Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt

[Brian Haberman]

Dave Thaler wrote:
>>From: Brian Haberman [mailto:[EMAIL PROTECTED]]
>>
>>>>The more I think about it, the more I realize that "automagically"
>>>>creating the subnet-local scope zone id isn't going to work.
>>>>Especially with multiple prefixes per interface.
>>>
> 
> Why not?  Can you elaborate?
> Shouldn't it always be true that if any two interfaces have the
> same (non-link-local) subnet prefix, then their subnet-local
> zone id MUST be the same?

What happens to the zone ids when:

  1. Interface 1 has prefix1 and prefix2
  2. Interface 2 has prefix1 and prefix3
  3. Interface 3 has prefix2 and prefix4

> 
> 
>>>So, this would be consistent with the suggestion that we
>>>change the Addr Arch document to list subnet-local and larger
>>>scopes as administratively defined (instead of just admin-local
>>>and higher)?
>>
>>Yes.  Given the issues with magically setting the subnet-local
>>zone id when multiple prefixes are enabled on an interface I
>>would agree with that change.
> 
> 
> I would disagree with that change.
>  
> 
>>>Another possibility is that we could default to a non-multi-link
>>>subnet case and declare the default to be subnet-local scope
>>>== link-local scope.
>>
>>We may need this as well.  Typically, the default behavior for
>>any less than global scope zone id is that all interfaces are
>>in the same zone.  I don't think we want that behavior with
>>subnet-local, it should default to being equivalent to link-local.
> 
> 
> I agree.  This also is what we implemented.
> 
> 
>>>>>In other words, I think that routers should default to the
>>>>>single-link subnet case, unless mutli-link subnetting has been
>>>>>explicitly configured.
>>>>
> 
> I agree with one important clarification.
> "Explicitly configured" != "administratively configured".

Totally agree.
> 
> The zero-config counter argument is a box that is labeled as 
> having its default configuration be that interfaces are on the
> same subnet different but different links (e.g. guaranteed 
> to be different because they're different media, like an
> 802.11 access point with a wired Ethernet link).  Here
> the explicitly configuration was done by the factory, not
> by the admin.

Yep.

Brian


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 PROTECTED]

Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt

[Brian Haberman]

Margaret Wasserman wrote:
> 
> 
>> The more I think about it, the more I realize that "automagically"
>> creating the subnet-local scope zone id isn't going to work.
>> Especially with multiple prefixes per interface.
> 
> 
> So, this would be consistent with the suggestion that we
> change the Addr Arch document to list subnet-local and larger
> scopes as administratively defined (instead of just admin-local
> and higher)?

Yes.  Given the issues with magically setting the subnet-local
zone id when multiple prefixes are enabled on an interface I
would agree with that change.

Though, I would like to be able to do automatic configuration
of subnet zone ids if only one global prefix is configured
per interface. :)  That would be nice for the zero-config
router scenario using multi-link subnets.

> 
> Another possibility is that we could default to a non-multi-link
> subnet case and declare the default to be subnet-local scope
> == link-local scope.

We may need this as well.  Typically, the default behavior for
any less than global scope zone id is that all interfaces are
in the same zone.  I don't think we want that behavior with
subnet-local, it should default to being equivalent to link-local.

> 
>>> These are questions that need to be answered in the scoped address
>>> architecture.
>>
>>
>> I think the addressing architecture needs to address the comment
>> on automatically creating the subnet-local zone id.
> 
> 
> This might be somewhat difficult, since I don't think that the
> concept of zone IDs is mentioned in the Addr Arch.

If the change is made that subnet-local must be administratively
configured, you don't need to mention zone ids in the addr arch.

> 
>>> I think it would be a reasonable default for a router that is
>>> configured with the same prefix on two interfaces to assume that
>>> those interfaces are on the same link (same link-local zone), and
>>> in the same subnet-local zone.
>>
>>
>> But if they aren't on the same link, forwarding could break.
> 
> 
> So, does this mean that routers can't automagically configure
> link-local zone IDs, either?  I had always assumed that two links
> with the same prefix would be in the same link-local zone.  Is
> that an invalid assumption?

It is if you believe in multi-link subnets.  Otherwise, your
assumption works fine and my comment is invalid.  Now, do we
want to say (somewhere) that in order to identify multi-link
subnets:

  - the prefixes must match
  - the subnet zone ids must match

This would give us the ability to identify the link-local ==
subnet-local case from the subnet-local > link-local case.

> 
>>> In other words, I think that routers should default to the
>>> single-link subnet case, unless mutli-link subnetting has been
>>> explicitly configured.
>>
>>
>> This is slightly different than assuming that the interfaces are
>> on the same link.  If the router treats them as unique prefixes,
>> then forwarding and routing should work.
> 
> 
> How would routing and forwarding work?  If the router thinks that
> it has two "unique" unicast prefixes that are both prefix1::/64, how
> will it know where to send a packet to prefix1::1?  Without
> explicit host routes (which is the solution that Steve preferred in
> the multi-link subnet case), there is no way to know whether or
> not to forward a packet to that address.

Host routes would work.  Another possibility (though I haven't
thought it all the way through) would be to utilize NDP by sending
out NS's on both interfaces.  This doesn't work if prefix1::1
exists on both nets.

Brian



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 PROTECTED]

Re: Fwd: [ipv6mib] So, where were we?

[Brian Haberman]

Juergen,
 So, should we look at trying to simplify the indices for the
tables?  That would seem like the logical thing to me.

Brian

Juergen Schoenwaelder wrote:
> 
> > Michael MacFaden writes:
> 
> Michael> Given the history of the IP-FORWARD-MIB: ipRouteTable,
> Michael> ipForwardTable, and the ipCidrRouteTable a minimalist
> Michael> approach might mean we have a higher probability that can get
> Michael> this new work to full standard.
> 
> The problem with the IP-FORWARD-MIB is that many systems use
> forwarding bases which are much richer than what the indexing allows
> to report. On such systems, implementing the ipCidrRouteTable (and the
> ipRouteTable) means to report only a subset of the real forwarding
> information. Hence, management applications which try to interpret
> these MIB tables are kind of fooled. This is of course even worse on
> systems that only have ipRouteTable support.
> 
> If we really care about interoperable management applications, then we
> need to spell out very clearly that an IP version independent variant
> of the ipCidrRouteTable is only applicable on devices where the
> complete forwarding information can be represented in the
> ipCidrRouteTable. (And it is my understanding that for example a
> recent Linux box would not fit into this category.)
> 
> We can try to improve this by adding more stuff into the index.
> However, we will end up with something that is getting even harder to
> implement correctly. And we all know that retrieving routing tables of
> non-trivial size via SNMP is already one of the slowest operations you
> can do on some boxes.
> 
> So while I in general like incremental approaches, I am not sure this
> really works out in the particular case of the IP-FORWARD-MIB.
> 
> /js
> 
> --
> Juergen Schoenwaelder
> --
> !! This message is brought to you via the `ipv6mib' mailing list.
> !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust
> !! your settings, send a mail message to <[EMAIL PROTECTED]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/ipv6mib.

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 PROTECTED]

Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt

[Brian Haberman]

Margaret Wasserman wrote:
> 
>>
>> Good catch Margaret.  I should have noticed that the example given
>> actually violates the scoped addressing architecture doc.  The
>> forwarding logic is still correct, but you can only have, at most,
>> one zone id per scope per interface.  Otherwise you would have
>> overlapping scope zones.
> 
> 
> Are you sure?
> 
> I originally began an answer to Robert's third example with something
> like "this is an invalid configuration".  However, I realized that I
> was mistaken.

If the rule stands that an interface can have no more than one
zone id per scope, then it is invalid if we expect a subnet-local
zone id to automatically appear when a prefix is configured on
an interface.

So, going back to Robert's example:

A - B - C

 - A-B is prefix1::/64 and prefix3::/64
 - B-C is prefix2::/64 and  prefix3::/64
 - (prefix1 != prefix2, prefix1 != prefix3, prefix2 != prefix3)

As long as B has one subnet-local scope zone id per interface,
the forwarding logic I described will work.

You could make it work with multiple zone ids on an interface,
but the logic would require a complicated RPF check on the
source address in order to determine which zone id to use in
the forwarding decision.  I don't think I want to go there.

> 
> Assuming that router B has support for multi-link subnets, Robert's
> example is a valid configuration showing a subnet-local zone
> that encompasses two links.

It is valid from the base architecture.  It is valid from the
scoping architecture if there is no more than one subnet-local
scope zone id.

> 
> There is no requirement that all hosts within a given zone need
> to configure addresses from (all of) the unicast prefix(es)
> within that zone, or that all routers need to advertise the same
> unicast prefixes on all interfaces within a given zone.  Is there?

Not that I know of.

> 
> The real question is this:
> 
> By default, if a router is configured to advertise the same prefix
> on two interfaces, should the router assume that the two interfaces
> are in the same subnet-local zone?  Should the router assume that
> the two interfaces are on the same link (i.e. in the same link-local
> zone)?

The more I think about it, the more I realize that "automagically"
creating the subnet-local scope zone id isn't going to work.
Especially with multiple prefixes per interface.

> 
> These are questions that need to be answered in the scoped address
> architecture.

I think the addressing architecture needs to address the comment
on automatically creating the subnet-local zone id.

> 
> I think it would be a reasonable default for a router that is
> configured with the same prefix on two interfaces to assume that
> those interfaces are on the same link (same link-local zone), and
> in the same subnet-local zone.

But if they aren't on the same link, forwarding could break.

> 
> In other words, I think that routers should default to the
> single-link subnet case, unless mutli-link subnetting has been
> explicitly configured.

This is slightly different than assuming that the interfaces are
on the same link.  If the router treats them as unique prefixes,
then forwarding and routing should work.

Brian


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 PROTECTED]

Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt

[Brian Haberman]

Margaret Wasserman wrote:
> 
> I'm not sure, though, that Brian's explanation is consistent with the
> following line in the scoped address architecture:
> 
> "Each interface belongs to exactly one zone of each possible scope."
> 
> Based on Brian's explanation, it would seem like the interfaces of
> router B are actually each in two subnet-local zones, and router B
> is using the source address of received packets to choose between
> them.  Brian?

Good catch Margaret.  I should have noticed that the example given
actually violates the scoped addressing architecture doc.  The
forwarding logic is still correct, but you can only have, at most,
one zone id per scope per interface.  Otherwise you would have
overlapping scope zones.

Brian



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 PROTECTED]

Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt

[Brian Haberman]

Robert Elz wrote:
> Date:Sun, 06 Oct 2002 10:38:32 -0400
> From:Margaret Wasserman <[EMAIL PROTECTED]>
> Message-ID:  <[EMAIL PROTECTED]>
> 
>   | You haven't provided the information that router B would use
>   | to make that determination.
> 
> Brian Haberman provided an entirely good enough answer (which also was
> that there wasn't enough information, but with different missing info).
> 
>   | Is router B configured so that the subnet-local zone IDs of its
>   | A-B and C-D interfaces are the same or different?
> 
> What subnet local zone id ?

A border router between subnet local zones will have subnet
zone ids assigned to each interface (see sections 5 & 6 of
draft-ietf-ipngwg-scoping-arch-04.txt).

> I wasn't aware that such a thing existed?
> If it did, it would have to be assigned, which would make subnet-local
> multicast jump out of the category of "no special config required"
> that is (I think rightly) claimed for it, wouldn't it?

Not necessarily.  This was covered in a previous thread, but it
is possible that a router could detect that a common prefix has
been assigned to multiple interfaces and set the subnet-local
zone id appropriately.

> 
>   | The unicast addresses uses on those links are immaterial to the
>   | decision of whether or not to forward subnet-local packets between
>   | these two links.
> 
> Hmm ... that is exactly the opposite of what Brian said, and is also
> contrary to what (little) I know about multicast forwarding.  Generally
> that's done based upon the (unicast) source address of the packet (along
> with the destination address, naturally).

Section 9 of draft-ietf-ipngwg-scoping-arch-04.txt explicitly states
that when forwarding packets with a less than globally scoped
destination address, the scope of the source address and the incoming
interface zone id are taken into account.

Brian


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 PROTECTED]

Re: Fwd: [ipv6mib] So, where were we?

[Brian Haberman]

Robert Elz wrote:
> 
> The only thing to be aware of, is that we (IPv6) must avoid getting upset
> if we do lots of work to update some particular MIB, and then just before
> we're finished, a new better version emerges from elsewhere (which is
> intended to deprecate some current v4 only MIB).  If that happens, we
> should just junk whatever we have done, and accept the newer one.

As long as the newer, better version supports IPv6.  We do have the
responsibility of ensuring v6 support in the new MIBs.

As a note, the IPv6 MIB Design Team has been reviewing new MIBs that
come out to make sure they are using the INET Address TC where
appropriate.

Brian


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 PROTECTED]

Re: Fwd: [ipv6mib] So, where were we?

[Brian Haberman]

> It is possible that we could do a combined version of these
> two choices:
> 
> - The IPv6 WG does the minimal updates to make the
> current IPv4 MIBs version-independent.
> - State-of-the-art MIBs are developed in other areas
> and groups, as appropriate.
> 
> What do you folks think?

I agree with this proposal.  The existing work of the IPv6 MIB
Design team should be targeted towards making the minimal updates.

State-of-the-art MIBs should be undertaken by subject matter
experts.

Brian


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 PROTECTED]

Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt

[Brian Haberman]

>   | >Every router (whether IPv4 or IPv6) knows what subnets its own interfaces
>   | >belong to (or, more accurately, what subnet numbers are assigned to
>   | >the links to which it has interfaces).  That is the most basic
>   | >configuration info provided to a router -- it is provided with that info
>   | >in order to do unicast routing and forwarding.  To enforce subnet-local
>   | >scope it is necessary simply to inhibit the forwarding of subnet-local-
>   | >destined packets between interfaces that do not belong to the same subnet.
> 
> 
> If I have
> 
>   A - B - C
> 
> and A-B is prefix1::/64 and B-C is prefix2::/64 and prefix1 != prefix2
> then subnet local multicast packets are not forwarded through B, right?

Yes.

> 
> If I have
> 
>   A - B - C
> 
> and A-B is prefix3::/64 and B-C is prefix3::/64 (a multi-link subnet)
> then subnet local multicast packets are forwarded through B, right?

Yes.

> 
> And if I have
> 
>   A - B - C
> 
> And A-B is prefix1::/64 and prefix3::/64, and B-C is prefix2::/64 and 
> prefix3::/64 (prefix1 != prefix2, prefix1 != prefix3, prefix2 != prefix3)
> then subnet local multicast packets arriving at B are .   ???

What is the source address of the subnet-local multicast address?
Section 9, bullet 2 in the scoped addressing architecture doc describes
the forwarding logic for this case.  If the packet was sourced out
of prefix3, it would be forwarded.  If it was sourced out of one of
the other prefixes, it would be dropped.

Brian


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 PROTECTED]

Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt

[Brian Haberman]

Rob Austein wrote:
> 
> At Wed, 02 Oct 2002 17:35:37 -0400, Brian Haberman wrote:
> >
> >  The subnet-scope is delineated in the same manner as the scopes
> > 6,7,8,9...  That is, a router maintains a scope zone id per interface.
> > So, if I have a router that has interfaces 1,2,3, & 4 and the admin
> > assigns a subnet-local scope zone id of 100 to interfaces 2 and 4,
> > then 2 and 4 are in the same subnet scope zone and multicast packets
> > received on one of those interfaces can only be sent to the other
> > interface with the same scope zone id.
> 
> The key phrase in your explanation is "the admin assigns".  The
> addr-arch doc says "admin-local scope is the smallest scope that must
> be administratively configured".  So which is it?

Ah, I missed that addition to the text.  But, the handling from a
forwarding and routing point of view is the same (via the settings
of the scope zone id).

As for the setting of the scope zone ids.  Those can be derived by
the prefix configuration on each interface.  If the prefixes on
interfaces 2 and 4 above are the same, the scope zone id will be
the same.

And I believe that Steve addressed the issue of unnumbered links in
a different message.

Regards,
Brian


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 PROTECTED]

Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt

[Brian Haberman]

Rob,
 The subnet-scope is delineated in the same manner as the scopes
6,7,8,9...  That is, a router maintains a scope zone id per interface.
So, if I have a router that has interfaces 1,2,3, & 4 and the admin
assigns a subnet-local scope zone id of 100 to interfaces 2 and 4,
then 2 and 4 are in the same subnet scope zone and multicast packets
received on one of those interfaces can only be sent to the other
interface with the same scope zone id.

 This is discussed in the Scoped Addressing Architecture in the
routing section.

Brian

Rob Austein wrote:
> 
> I made the mistake of allowing my arm to be twisted into reviewing
> draft-ietf-ipngwg-addr-arch-v3-10.txt last week, and was sad to find
> what appears to be an ambiguity in some of text that deals with
> subnet-scope multicast.  Given that this document was already before
> the IESG at the time I found this, I've been discussing this with our
> AD, who brought in our WG chairs once he and I agreed that there might
> be a problem here, but we felt that the discussion of what to do about
> this really should take place out in the open on the WG mailing list.
> 
> So, what I said (after some initial clarifying discussion) was:
> 
>   In the absence of a precise definition of the distinction between a
>   link and a subnet, it is unclear what a router should do with a packet
>   addressed to a transient multicast address with subnet-local scope.
>   Excerpting from the draft:
> 
>2  link-local scope
>3  subnet-local scope
>4  admin-local scope
> 
>...
> 
>link-local and site-local multicast scopes span the same
>topological regions as the corresponding unicast scopes.
> 
>subnet-local scope is given a different and larger value
>than link-local to enable possible support for subnets
>that span multiple links.
> 
>admin-local scope is the smallest scope that must be
>administratively configured, i.e., not automatically
>derived from physical connectivity or other, non-
>multicast-related configuration.
> 
>   So subnet-local is a larger scope than link-local, and may be derived
>   automatically from physical connectivity (in some completely
>   unspecified way!).  So what should a router do with that packet?  To
>   forward or not to forward, that is the question.
> 
>   One could address this concern by adding text (somewhere) to the
>   effect that, until such time as a standards track document specifies
>   how a router should determine what the subnet-scope boundaries are and
>   what a router should do with an otherwise valid packet addressed to a
>   multicast address with scop set to subnet-local, routers should handle
>   such packets precisely as they would if scop were set to link-local.
>   Or something like that.
> 
> 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 PROTECTED]
> 

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 PROTECTED]

Re: Link local address for tunnel interfaces

[Brian Haberman]

Mukesh Gupta wrote:
> Hi,
> 
> Is it required to have a link local address on a tunnel interface. I am
> implementing IPv6 in IPv6 tunnels and wanted to know whether I should
> install a link local address on the tunnel interface. Is there any
> document that talks about this ?

RFC 2373, Section 2.8 requires that a node recognize itself by
"Its Link-Local Address for each interface".  That would include
any virtual interfaces created by a tunnel.

> 
> If it is required, how should I calculate a unique link local address ?

Appendix A of 2373 discusses creating EUI-64 identifiers which
can be used in the creation of link-local addresses.

Regards,
Brian


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 PROTECTED]

MAGMA WG Last Call: draft-ietf-magma-mld-source-01.txt

[Brian Haberman]

All,
  This starts the MAGMA Working Group 2 week Last Call
period for draft-ietf-magma-mld-source-01.txt.  The Last Call
will end on October 3rd.  Substantive comments should be
directed to the MAGMA mailing list.  Editorial comments can
be made to the author.

Regards,
Brian & Bill


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 PROTECTED]

MLD source address selection draft

[Brian Haberman]

All,
 Several people have mentioned the conflict that exists between
the MLD spec (RFC 2710) and NDP (RFC 2461).  NDP requires nodes to
join the solicited-node multicast address in order to perform Address
auto-config.  However, MLD requires the source IPv6 address to be a
valid link-local address.  So, I have cobbled together a short draft
to clarify the source address selection criteria for MLD.  It only
applies to 2710 (not the MLDv2 draft that already takes care of the
problem).  The draft is available in the draft repository at
http://www.ietf.org/internet-drafts/draft-ietf-magma-mld-source-00.txt.

 Comments should be directed to me or the magma mailing list.

Brian

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 PROTECTED]

Re: Flow label draft issues & new text

[Brian Haberman]

Margaret Wasserman wrote:
> 
> >If
> >you want to talk DiffServ, IntServ, or something of that flavor, the
> >flow label would be signaled, the router would recognize it during
> >packet classification and deal with it how it sees fit.
> 
> So, all of the routers would have to participate in signalling to
> know whether the flow label was used for DiffServ, IntServ, etc.?
> 
> Or, it would just work to use the flow label for load balancing,
> even it it contained a DiffServ or IntServ value, instead of
> labeling a microflow?

How DiffServ and IntServ work with the flow label is yet to be
determined.  All I am saying is that the current spec does not
preclude any of the functions mentioned above.  Isn't that the
point of the draft?

As Matt said, the host knows best what a flow is.  Whether that
flow gets signaled to routers for special handling or not is
outside the scope of this doc.

Brian

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 PROTECTED]

Re: Flow label draft issues & new text

[Brian Haberman]

Michael Thomas wrote:
> 
> Margaret Wasserman writes:
>  >
>  > If the WG really wants to define the flow label so that it can be used
>  > for signalling-based mechanisms like RSVP, NSIS and diffserv, with the
>  > clear understanding that this makes the value _USELESS_ for the types
>  > of applications I've described above, that is fine with me.
> 
>I'm still completely lost. How does it make it
>useless?

I must be lost as well.  In my reading of the flow label spec, I see
the capability to do load balancing quite easily.  The host sending
the data assigns unique flow labels however it wants (just like Erik
had mentioned).  The routers can then either forward based solely on
the DA or it can hash the  for load balancing.  If
you want to talk DiffServ, IntServ, or something of that flavor, the
flow label would be signaled, the router would recognize it during
packet classification and deal with it how it sees fit.

So, my opinion is that the spec does what it set out to accomplish.

Brian

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 PROTECTED]

MAGMA WG Last Call for MLDv2: draft-vida-mld-v2-03.txt

[Brian Haberman]

All,
 This is the start of a MAGMA working group last call on the
Multicast Listener Discovery - Version 2 specification.  
http://www.ietf.org/internet-drafts/draft-vida-mld-v2-03.txt
The last call period will end on August 13th.  Substantive comments
should be directed to MAGMA mailing list.  Editorial comments should
be directed to the authors.

Regards,
Brian & Bill
MAGMA co-chairs

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 PROTECTED]

Re: IPv6 Flow Label Specification

[Brian Haberman]

[EMAIL PROTECTED] wrote:
> 
> >> I don't disagree with you - however my point was I thought that the
> >> application should be involved in what value of the flow label is used.
> >
> >Is it really the case that the application needs to be involved in
> >choosing the flow label value?  Or is it more reasonable to say that
> >the app needs to be able to indicate that it wants to use *a* flow
> >label?
> >
> >I can see the flow label management issue being more efficient in
> >the IPv6 stack itself.
> 
> FYI, draft-itojun-ipv6-flowlabel-api-01.txt provides no way to
> set flowlabel value from the userland.  the (sending) kernel decides
> the value.  receiver apps can inspect the value.

Exactly.  I prefer that rather than one that requires the apps to make
a decision on the value.

Brian

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 PROTECTED]

Re: IPv6 Flow Label Specification

[Brian Haberman]

Hi John,

[EMAIL PROTECTED] wrote:
> 
> I don't disagree with you - however my point was I thought that the
> application should be involved in what value of the flow label is used.

Is it really the case that the application needs to be involved in
choosing the flow label value?  Or is it more reasonable to say that
the app needs to be able to indicate that it wants to use *a* flow
label?

I can see the flow label management issue being more efficient in
the IPv6 stack itself.

Of course, there is also an issue of whether two applications on
the same machine communicating with the same peer machine would want
to share a flow label.

Brian

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 PROTECTED]

Re: Request for Agenda Items for IETF 54 IPv6 Sessions

[Brian Haberman]

Francis,
 I agree that prefix delegation is important for the home sites.
Unfortunately, I will not be at IETF 54 to discuss my prefix delegation
work.  If it becomes an agenda item, I will see about getting someone
to participate for me.

Regards,
Brian

Francis Dupont wrote:
> 
>  In your previous mail you wrote:
> 
>=> Francis Dupont wrote:
>=> I strongly encourage items about prefix delegation for
>=> home sites because these are *urgent* for IPv6 deployment.
> 
>I must have missed something. Can you develop this / post links?
> 
> => today ISP which manages an IPv6 dialup service (i.e., its customers
> run "home sites") should allocate a /48 per connection but there is
> no available protocol to do this. It seems the only way is static
> delegation/configuration and this is very heavy and not scalable at all.
> So if you believe the "home site" case is important for IPv6 deployment,
> we have to solve many problems and the prefix delegation is the first one
> (and as this is a problem for both the ISP and its customers, its value/cost
> doubles :-).
> 
> Regards
> 
> [EMAIL PROTECTED]
> 
> 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 PROTECTED]
> 

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 PROTECTED]

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

[Brian Haberman]

Oops.  My mistake.

Brian

Michel Py wrote:
> 
> Brian,
> 
> > And if you want to use AS numbers, just remember that a 64 bit
> > AS number will not fit inside 37 bits.
> 
> I don't think this is a good argument. Today, the AS number is 16 bits.
> Tomorrow, it will be 32, which is 4 Billion AS numbers. 37 bits would be
> 128  Billion AS numbers, probably more than we need.
> 
> Michel.

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 PROTECTED]

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

[Brian Haberman]

Tony,

Tony Hain wrote:
> 
> Keith Moore wrote:
> > ...
> > of course it's a global address.  but that doesn't mean it's globally
> > routable.
> 
> You have just argued yourself into a corner. If the address the app
> chooses is not globally routable, how does it connect? Why would it have
> chosen SL over the PA prefix to begin with? Wouldn't it make more sense
> to avoid the possibility of being black-holed? You are looking for
> addresses that are both locally administered (for the site that is not
> attached), and globally routable (for the app to actually connect in any
> arbitrary case with nodes outside the private network), but recognizing
> those are mutually exclusive. The reason I have gleaned from this thread
> is that you don't want the app to have to worry about scope. How can it
> avoid worrying about scope if your preferred address mechanism doesn't
> go everywhere?
> 
> Functionally the scope mechanism provides a much cleaner decision point
> for an app than a nebulous expansion of SL to include globally unique
> site-ids. Again I have no problem with locally administered site-ids,
> because those are routed within the context of the private network so an
> app can rely on them. If the app wants to connect outside the scope of
> the private network, it really needs to be using a global address, or
> have lots more knowledge about current routing policy than anyone will
> ever share with an app.

Thank you.  I completely agree.

Brian

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 PROTECTED]

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

[Brian Haberman]

Keith Moore wrote:
> 
> > > > I think there are lots of reasons not to make these site-ids globally
> > > > unique, if we choose to adopt them.
> > >
> > > name one.
> >
> > The cost of administration of the global database.
> 
> there doesn't need to be a global database.  try again.

If there isn't a global administration db:

 1. How do we know a site-id is unique?
 2. How do we know who owns the site-id?

And if you want to use AS numbers, just remember that a 64 bit AS number
will not fit inside 37 bits.

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 PROTECTED]

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

[Brian Haberman]

Keith Moore wrote:

> > I think there are lots of reasons not to make these site-ids globally
> > unique, if we choose to adopt them.
> 
> name one.

The cost of administration of the global database.

Brian

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 PROTECTED]

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

[Brian Haberman]

Keith Moore wrote:
> 
> > Who delegates the globally-unique site-ids?
> 
> presumably ICANN or their designees.

This introduces a management headache.  The address registries already
are struggling with managing the global address space.  Adding another
registry will not be beneficial.

> 
> > If the site-ids are
> > globally unique, how are they any different from global addresses?
> 
> they have a different prefix so they can easily be distingiushed
> from public addreses.

But with a globally unique site-id, they are globally routable.  What's
the point?  If the site local addresses are used within a private
network, there is no need for a global registry since they won't be
seen in the global Internet.

Brian

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 PROTECTED]

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

[Brian Haberman]

Keith,

Keith Moore wrote:
> 
> if you have enough bits for the site-id you can make the probability
> of a conflict approach zero *provided* the site bits are randomly
> chosen.   but the easiest way to avoid conflicts is to make the
> site-id globally unique, and there's no good reason to not do so.

Who delegates the globally-unique site-ids?  If the site-ids are
globally unique, how are they any different from global addresses?

Brian

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 PROTECTED]

Re: Consensus on Site-Local Discussion

[Brian Haberman]

Keith,

Keith Moore wrote:
> 
> in other words, I think we need to seriously question some of the assumptions
> behind the scoped addressing architecture, and I'm not confident that
> "completing the work on the Scoped Address Architecture document" will
> accomplish that.

Can you enumerate what assumptions you are concerned about?  That would
give us the authors a better understanding of your concerns.

Brian

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 PROTECTED]

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

[Brian Haberman]

Vlad,
 Not at all.  The zone IDs are not included in the route
advertisement messages.  That simplifies things a great deal since
you don't have to coordinate the zone IDs across a site.  The zone
IDs only have meaning on the node in which they are used.

Brian

Vladislav Yasevich wrote:
> 
> Brian
> 
> Wouldn't the Zone ID for a given site on all routers in that same site
> have to be same for this to work?
> 
> -vlad
> 
> Brian Haberman wrote:
> > Hi Margaret,
> >  I suppose that I should admit to being remiss in this area.  I
> > have done a fair amount of work in this area and just haven't had the
> > time to document routing protocol behavior changes to support site
> > local prefixes (even though I recall telling you I was going to do it).
> >
> >  Anyway, I will start by saying that I have modified RIPng to
> > correctly handle the advertisement of site-locals.  In order to make
> > this efficient, I maintained the concept of a single instance of RIPng
> > running in the router.  In order to understand the changes to the
> > routing protocol, you also have to understand the changes to the
> > RIB for site locals.  So, how did I make it work?
> >
> >  1. The RIB now contains an additional field, the zone ID.  I
> > have done this in two different ways.  The first is to add
> > the zone ID as a separate field.  The second is to embed
> > the zone ID in the "unused" portion of the site local
> > prefix.
> >
> >  2. RIPng was changed to build its route advertisement messages
> > on a per zone ID basis.  That is, it starts with adding all
> > global prefixes to the message.  It then adds site local
> > prefixes that are in the same zone ID as the interface that
> > the advertisement will be transmitted.  It determines this
> > by extracting the zone ID from the outgoing interface and
> > using this find all site locals in the RIB with a matching
> > zone ID.
> >
> >  3. When RIPng receives a route advertisement from a peer, it
> > takes the zone ID from the receiving interface and using
> > that to add the site local prefixes to the RIB.
> >
> > That, in a nutshell, allows a single instance of RIPng to control
> > the advertising of site local unicast prefixes.  Though I haven't
> > done the work, I would see OSPF as acting in a similar manner.
> >
> > If someone wants me to describe the actual forwarding, just let me
> > know.
> >
> > Regards,
> > Brian
> >
> > Margaret Wasserman wrote:
> >
> >>I sent the attached message to the routing area discussion list.  I thought that 
>people on
> >>the IPv6 list might be interested in this discussion, so I will forward a message 
>containing
> >>the responses after this one.  I suppose I just should have cc:ed the IPv6 group 
>in the
> >>first place...
> >>
> >>Margaret
> >>
> >>
> >>>Date: Fri, 24 May 2002 12:17:04 -0400
> >>>To: [EMAIL PROTECTED]
> >>From: Margaret Wasserman <[EMAIL PROTECTED]>
> >>>Subject: IPv6 Scoped Addresses and Routing Protocols
> >>>
> >>>
> >>>
> >>>Hi All,
> >>>
> >>>I raised some questions with Bill Fenner in Minneapolis regarding IPv6 scoped
> >>>addressing and our current IPv6 routing protocol specifications, and Bill 
>suggested
> >>>that I should send my questions to this list for discussion.  So, here they are.
> >>>
> >>>First, some background...
> >>>
> >>>As many of you probably know, IPv6 includes the concept of scoped unicast
> >>>addressing -- a unicast address can have link-local scope, site-local scope
> >>>or global scope.  The address scopes are defined in the IPv6 Addressing
> >>>Architecture:
> >>>
> >>>http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.txt
> >>>
> >>>Additional information can be found in the IPv6 Scoped Address
> >>>Architecture:
> >>>
> >>>http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-03.txt
> >>>
> >>>I would suggest that all of you read the IPv6 Scoped Address Architecture
> >>>document, if you haven't already, as it contains information regarding
> >>>the expected configuration and forwarding behaviour of IPv6 routers.
> >>>It also defines the concept of a

Re: Reviewof"Use of /127 Prefix Length Between Routers Considered Harmful"

[Brian Haberman]

> Place this in context: what we are talking about here is either a
> router-to-router tunnel or a router-to-router link. Guess what: there is
> likely to be a routing protocol there. Could you explain me how you
> configure RIP when the other router is not on the same subnet?

In all of my labs where I have had p2p links like that, both
ends of the link only have link-local addresses and RIPng works
just fine.


IPv6 cloud --- RTR1 --- p2p --- RTR2 ---IPv6 cloud

Each router has a global address and a link-local address on the
cloud interfaces and link-local addresses on the p2p.  RIPng
running and reachability everywhere.

Brian


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 PROTECTED]

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

[Brian Haberman]

Steve,

"Steven M. Bellovin" wrote:
> Yah.  Let's pick a prefix, and tell folks to pick a random number (more
> precisely, use an RFC 1750-compatible RNG) to fill out the rest of the
> high-order bits to a /48 or a /64.  We encourage ISPs to provide real
> prefixes to companies that are using application-layer gateways, and
> hence don't "need" a routable prefix.  We promise two months of
> connectivity to folks using non-conflicting random prefixes when they
> connect, while they renumber.  We think of other, creative solutions
> that exploit the fact that we have a really large address space that
> we're not going to exhaust.
> 
> In short, that we do *something* that isn't going to cause long-term
> architectural and operational pain.

I suggested several years ago that the site-local prefixes could
contain more info to help "identify" it.  I was told that it had
been discussed and was not beneficial enough.  Adding an AS # or
some other identifier would definitely help clarify the prefixes.

Brian

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 PROTECTED]

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

[Brian Haberman]

Ralph,

Ralph Droms wrote:
> And, I don't think there's a good way to define default behavior
> or auto-discovery for site-local addressing...

Well, we could very easily apply RFC 2776 to the problem.  It is
already designed to advertise multicast zones.  I may not help
with auto-configuring the borders, but it will help debug them.

Brian

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 PROTECTED]

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

[Brian Haberman]

Hi Margaret,
 I suppose that I should admit to being remiss in this area.  I
have done a fair amount of work in this area and just haven't had the
time to document routing protocol behavior changes to support site
local prefixes (even though I recall telling you I was going to do it).

 Anyway, I will start by saying that I have modified RIPng to
correctly handle the advertisement of site-locals.  In order to make
this efficient, I maintained the concept of a single instance of RIPng
running in the router.  In order to understand the changes to the
routing protocol, you also have to understand the changes to the
RIB for site locals.  So, how did I make it work?

 1. The RIB now contains an additional field, the zone ID.  I
have done this in two different ways.  The first is to add
the zone ID as a separate field.  The second is to embed
the zone ID in the "unused" portion of the site local
prefix.

 2. RIPng was changed to build its route advertisement messages
on a per zone ID basis.  That is, it starts with adding all
global prefixes to the message.  It then adds site local
prefixes that are in the same zone ID as the interface that
the advertisement will be transmitted.  It determines this
by extracting the zone ID from the outgoing interface and
using this find all site locals in the RIB with a matching
zone ID.

 3. When RIPng receives a route advertisement from a peer, it
takes the zone ID from the receiving interface and using
that to add the site local prefixes to the RIB.

That, in a nutshell, allows a single instance of RIPng to control
the advertising of site local unicast prefixes.  Though I haven't
done the work, I would see OSPF as acting in a similar manner.

If someone wants me to describe the actual forwarding, just let me
know.

Regards,
Brian

Margaret Wasserman wrote:
> 
> I sent the attached message to the routing area discussion list.  I thought that 
>people on
> the IPv6 list might be interested in this discussion, so I will forward a message 
>containing
> the responses after this one.  I suppose I just should have cc:ed the IPv6 group in 
>the
> first place...
> 
> Margaret
> 
> >Date: Fri, 24 May 2002 12:17:04 -0400
> >To: [EMAIL PROTECTED]
> >From: Margaret Wasserman <[EMAIL PROTECTED]>
> >Subject: IPv6 Scoped Addresses and Routing Protocols
> >
> >
> >
> >Hi All,
> >
> >I raised some questions with Bill Fenner in Minneapolis regarding IPv6 scoped
> >addressing and our current IPv6 routing protocol specifications, and Bill suggested
> >that I should send my questions to this list for discussion.  So, here they are.
> >
> >First, some background...
> >
> >As many of you probably know, IPv6 includes the concept of scoped unicast
> >addressing -- a unicast address can have link-local scope, site-local scope
> >or global scope.  The address scopes are defined in the IPv6 Addressing
> >Architecture:
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.txt
> >
> >Additional information can be found in the IPv6 Scoped Address
> >Architecture:
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-03.txt
> >
> >I would suggest that all of you read the IPv6 Scoped Address Architecture
> >document, if you haven't already, as it contains information regarding
> >the expected configuration and forwarding behaviour of IPv6 routers.
> >It also defines the concept of an IPv6 site, which is important to understanding
> >the questions that I am about to raise.
> >
> >In IPv6, there is a concept of site-local addressing that is quite different
> >from the concept of "net 10" addresses in IPv4.  Sites are administratively
> >defined entities that must be "convex" (i.e. the best route between two nodes
> >in the site must, at all scopes, fall completely within the site).  Sites boundaries
> >run through routers, so a single router (called a site border router (SBR)) can
> >have interfaces in more than one site.  And, IPv6 site-local addresses can be
> >used for site-constrained communication, even when a site is globally
> >connected and global addresses are available.
> >
> >Because all site-local addresses use the same well-known site-local prefix, the
> >only way to tell that a particular site-local address belongs to a particular
> >site is to know which site originated the address.  SBRs will need
> >to enforce site boundaries, not mixing site-local routing information, and not
> >forwarding packets outside of a given site.  To do this, it is expected that
> >SBRs will need to maintain multiple "conceptual routing tables", including one
> >site-local routing table for each attached site, and one global routing table.
> >
> >Unfortunately, I can't find any indication that these concepts have been reflected
> >in the current IPv6 routing protocols.  None of our IPv6 routing protocol documents
> >deal with site-local boundaries or 

Re: Text for MLD - cellular host draft

[Brian Haberman]

Jari,

> But I do understand that the RFCs must be followed.
> However, I wonder if you Brian could say something
> about the background for the link-local and the
> Solicited Node multicast address requirements,
> were they done specifically to allow switches to operate
> or for some other reason?

Using MLD to signal interest in link-local multicast addresses
allows for two things:

 1. Signal interest in a group to all link-local
listeners (hosts and routers)

 2. Allowing switches to properly forward link-local
multicast addresses

In the specific case of GGSN <--> UE, there are no switches
and the GGSN has already configured the UE with the Interface
ID.  So, the GGSN already knows what the corresponding Solicited
Node multicast address will be.  In that case, sending an MLD
Report will not benefit either the GGSN or the UE.

> 
> I also wonder about text in Section 2, which says
> that  MLD should be on all interfaces from which
> an application or upper-layer protocol has requested
> reception of multicast packets. I wonder what "upper
> layer" means in this particular case...? If it
> means above IP then we could argue that we are following
> the RFC.

It means any code in the device that wishes to utilize IP
multicast.  Neighbor Discovery qualifies by that definition
and it is the primary user of the Solicited Node multicast
address.

I believe that the important text is the first paragraph of
Section 2:

   The purpose of Multicast Listener Discovery (MLD) is to enable
   each IPv6 router to discover the presence of multicast listeners
   (that is, nodes wishing to receive multicast packets) on its
   directly attached links, and to discover specifically which
   multicast addresses are of interest to those neighboring nodes.

Since the GGSN already knows which link-local multicast addresses
the UE is interested in, I believe the cellular host doc is
compliant with RFC 2710.

> 
> I also wonder if the timers -- which are configurable
> per the RFC -- could be tuned to minimize overhead?

Sure.  Section 7 of RFC 2710 defines all the timers and identifies
which ones can be modified.

One final comment.  The future evolution of 3GPP standards may
lead towards more usage of IP multicast (including the subnet-local
range).  If that occurs, 3GPP will have to look very closely at
how MLD (or MLDv2) fits in the architecture.

Regards,
Brian

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 PROTECTED]

Re: Text for MLD - cellular host draft

[Brian Haberman]

Hesham,
 The text looks fine to me.

Regards,
Brian

"Hesham Soliman (ERA)" wrote:
> 
> Hi all,
> 
> After some discussion on the list, I'd like to
> propose the following text for MLD in the cellular
> host draft:
> 
> 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6
> 
> MLD may be supported by cellular hosts.
> 
> 2.9.1 MLD in 3GPP networks
> 
> Within 3GPP networks, hosts are connected to their
> default routers (GGSN) via point-to-point links.
> Consequently, hosts cannot communicate directly with
>   each other using link-local addresses. Hence, joining
>   multicast groups for link-local multicast addresses is
>   not required. However, MLD is required when hosts run
>   applications that need to join multicast groups whose
>   scopes are larger than the link scope.
> 
> Is this acceptable?
> 
> Hesham
> 
> 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 PROTECTED]
> 

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 PROTECTED]

Re: IPv6 MIBs - internet draft status

[Brian Haberman]

Kristine,
 We will probably have a slot in one of the IPv6 WG sessions to
discuss the mib work.  It may also be presented at the ops area
meeting (if held).  At least, that is what we have done in the past.

Regards,
Brian

[EMAIL PROTECTED] wrote:
> 
> Thanks to everyone who responded regarding my status questions on the
> revised MIBs. Does anyone know if the IPv6 MIB design team is planning
> on scheduling a session at the Japan IETF to discuss the revised MIBs?
> Thanks!
> 
> Kristine Adamson
> IBM Communications Server for MVS: TCP/IP Development
> Internet e-mail:[EMAIL PROTECTED]

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 PROTECTED]