[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    (IPng 3722) Re:  comments on
From:       Bob Hinden <hinden () Ipsilon ! COM>
Date:       1997-05-28 22:02:11
[Download RAW message or body]

Brain,

Thanks for the thoughtful comments.

>I am concerned that in one respect part of the baby was lost
>with the bathwater - to do with multihoming & renumbering;
>there are specific comments about this later.
>
>There are also two places where the material is much more
>appropriate for BCP than standards-track; I think the document
>has to be split in two for that reason; again there are
>specific comments about this.

I came to the same conclusion, but thought it best to initially keep it
together for ease of review.  One the content is a bit more settled, I
would be happy to split it into two documents.

>....
>>  addresses.  Organizations who connect to these exchanges will also
>>  subscribe (directly, indirectly via the exchange, etc.)  for long-
>>  haul service from one or more long-haul providers.  Doing so, they
>>  will achieve addressing independence from long-haul transit
>>  providers.  They will be able to change long-haul providers without
>>  having to renumber their organization.  They can also be multihomed
>>  via the exchange to more than one long-haul provider without having
>>  to have address prefixes from each long-haul provider.
>
>yes but - this leaves open the whole question of provider selection.
>That cannot be resolved in this document but at least you need to say:
>
>   The way in which provider selection will be achieved for multihomed
>   organizations is not discussed in this document.

OK.

>>  IPv6 unicast addresses are designed assuming that the internet
>>  routing system makes forwarding decisions based on a "longest prefix
>>  match" algorithm on arbitrary bit boundaries and does not have any
>>  knowledge of the internal structure of IPv6 addresses.  The structure
>>  in IPv6 addresses is for assignment and allocation.  
>
>Not so. Assignment hierarchy has to match topology and renumbering
>is required when changing either exchange or upstream provider. These
>IPv6 addresses are *not* portable and this has to be nailed up
>very solidly in the spec. Add:

This paragraph is saying that implementations (e.g., code) are not aware of
the boundaries.  The boundaries are there for address allocation.  The routing
system works on addresses and masks.  Yes, the assignment does have to
match the topology.

>   However, aggregatable addresses as defined in this document are
>   also designed to be topologically significant such that they can
>   be scalably aggregated for routing purposes. For this reason, addresses
>   are only portable as long as the organization concerned stays attached
>   directly or indirectly to the same mid-level aggregator such as 
>   P2, P4 or X1 in the above example. 

I can add more detail on portability, etc.

>....
>> 3.2 Top-Level Aggregator
>>
>>  Top-Level Aggregators (TLA) are the top level in the routing
>>  hierarchy.  Default-free routers will, at a minimum, have a routing
>>  table entry for every active TLA. 
>
>Again, you lost something in the bathwater. I'd suggest:
>   
>   hierarchy. Default-free routers MUST have a routing
>   table entry for every active TLA. They MAY have additional
>   entries, but routing topology at all levels MUST be designed
>   to minimize the number of additional entries fed into the
>   default-free routing tables.

I will add the elaboration as you suggest.  

>>  TLA assignment requirements are as follows:
>>
>>   - Must have a plan to offer public native IPv6 service within 6
>>     months from assignment.  Plan must include plan for NLA
>>     allocation.
>>
>>   - Plan or track record providing public internet transit service to
>*****               on fair, reasonable and non-discriminatory terms^

Good idea.

>>     other providers.  TLAs should not be assigned to organization that
>                            ^MUST NOT^

Good.

>>     are only providing leaf service even if multihomed.
>
>>   - Must provide registry services for the NLA address space it is
>***** on fair, reasonable and non-discriminatory terms^
>>     responsible for under its TLA.  This must include both sites and
>>     next level providers.
>>
>>   - Must provide transit routing and forwarding to all assigned TLAs.
>***** on fair, reasonable and non-discriminatory terms^
>>     Organization is not allowed to filter out any specific TLA's
>>     (except temporarily for diagnostic purposes).
>or for emergency repair to services or emergency security protection.

Good on all of above.

>>   - Periodically (interval set by registry) provide to registry
>>     utilization statistics of the TLA it has custody of.  The
>      ^allocation
>>     organization must also provide traffic statistics on amounts of
>>     traffic for transit TLA traffic.
>
>You can't include that - it's illegal in some countries.

What is illegal in some countries?  Utilization statistics or traffic
statistics, or both?  Why?

>>  Organizations which are given custody of a TLA and fail to continue
>>  to meet these (or other future requirements defined by the IANA) may
>>  have the TLA custody revoked.
>
>Delete "future". You can't retrofit conditions to contracts

I can try can't I :-)

><<end of BCP material>>
>
>....
>>  The NLA delegation works the the same manner as CIDR delegation in
>>  IPv4 [CIDR].  
>*****         and MUST correspond to the routing topology as closely
>   as possible.

I think that at this level in the routing hierarchy it is a tradeoff of
routing aggregation v.s. routing/assignment flexibility.  As long as the
NLA routing does not propagate to the top level, then this is a tradeoff
which belongs to the organization responsible for the specific NLA.  I
could add some words to that effect.

>....               
>>  of the previous level NLA.  It is recommended that organizations
>>  assigning NLA address space use "slow start" allocation procedures as
>>  is currently done with IPV4 CIDR blocks.
>
>This is also BCP material, and it should be spelt out in a stand-alone
>way for IPv6, rather than a back-reference to a hopefully obsolete world.

Does the NLA stuff have to be in a separate BCP from the TLA or could they
be combined?

>>  The approach chosen for how to the structure of an SLA* field is the
>>  responsibility of the individual organization.
>
>   A large organization SHOULD use a hierarchical design
>   corresponding as closely as possible to its routing
>   topology.

As above, there is a tradeoff which should be left to the site.  How much
do you think needs to be said?

>>  serial links, tunnel end-points, etc.).  Where EUI-64 identifiers are
>>  used it is required that the "u" bit (universal/local bit in IEEE
>>  EUI-64 terminology) be set correctly.
>
>Define "correctly" (especially if the consensus is to flip the bit).

Correctly as defined in [ARCH] (as below).   I will clarify this.

>>  The construction of Interface Identifiers constructed in EUI-64
>>  format is defined in [ARCH].  The details on forming interface
>>  identifiers is defined in the appropriate "IPv6 over <link>"
>>  specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI"
>>  [FDDI], etc.
>
>I'd add as an FYI item that EUI-64 is a superset of 48-bit MAC space
>(and BTW does that mean that the "u" bit occurs twice?)

OK, but this document assume knowledge of the rules in [ARCH].  I am
working on an appendix to [ARCH] which describes the mapping of 48-bit =>
EUI-64 and alternatives for creating local scope interface identifiers.

>> 6.0 Security Considerations
>
>>  Documents of this type do not directly impact the security of the
>>  Internet infrastructure or its applications.
>
>Hmm. Not sure that you can say as little as this. For example where
>in the IPv6 document set do we discuss address spoofing atacks?
>At least I'd be tempted to say (most everywhere, not just in this
>document) that IPv6 is intrinsically insecure unless IPSEC is switched
>on, and specifically that IPSEC can be used to mitigate address spoofing.

I was given this text by an IESG member (who can identify him/herself if
he/she wishes).  I think it is sufficient for this document given it's
content.  Some of the other IPv6 specifications do need more on this topic. 

Thanks again for the comments.

Bob

--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]