Subject: rfc2772 and draft-ietf-v6ops-routing-guidelines

From: Marc Blanchet <[email-masked]>
Date: Mon, 19 Mar 2007 10:31:09 +0100

Responding to Alain's comment on why RFC2772 is not accurate these  
days and we need a new document that obsoletes it. This
email contains extracts from RFC2772.  Again, RFC2772 was fine at the  
time it was needed, but right now it is really not appropriate. One  
of the purposes of draft-ietf-v6ops-routing-guidelines is to make  
RFC2772 obsolete.

I'm really happy in getting suggestions on better title.
RFC2772 title: 6Bone Backbone Routing Guidelines
draft-ietf-v6ops-routing-guidelines title: IPv6 Routing Policies  
Guidelines

Suggestions for title?

Marc.
rfc2772.txt:

======================
<title>6Bone Backbone Routing Guidelines

MB:  title is no more applicable: either people will not read the  
document because of the title.

======================
<abstract>
    The 6Bone is an Ipv6 testbed to assist in the evolution and
    deployment of IPv6. Because of this, it is important that the core
    backbone of the IPv6 network maintain stability, and that all
    operators have a common set of rules and guidelines by which to
    deploy IPv6 routing equipment.

    This document provides a set of guidelines for all 6bone routing
    equipment operators to use as a reference for efficient and stable
    deployment of 6bone routing systems. As the complexity of the 6Bone
    grows,the adherence to a common set of rules becomes increasingly
    important in order for an efficient, scalable backbone to exist.
</abstract>

MB: again, abstract is no more applicable given its 6bone focus.

======================
<section>
2. Scope of this document

    This document is a best-practices Informational document aimed at
    IPv6 entities which operate under the 6Bone IPv6 testbed TLA
    allocation.
</section>

MB: again, no more applicable text.

======================
<all sections>
uses pTLA to describe backbone operators. no more applicable.

======================
<section>
3.1 Link-local prefixes
...

    "In such cases, vendors should be urged to correct their code.

MB: I'm not sure we need to have this advice in a current RFC.

======================
   " Should a pTLA discover link-local prefixes coming from another  
pTLA,
    it is the responsibility of the pTLA leaking the routes to filter
    these, and correct the problem in a timely fashion. "
  ...
     Failure to filter such routes in a timely fashion may result in the
    manual shutting down of BGP4+ sessions to that pTLA, from other
    pTLA's.

MB: in the context of the production IPv6 backbone, this looks more  
like how IETF tells the operators how to run their network. In the  
context of 6bone, it was ok, but these days, I'm not sure.

======================
3.2 Site-local prefixes

MB: site-locals were deprecated. this whole section is no more  
appropriate.

======================
3.5 IPv4 compatible prefixes

MB: ipv4-compatible were deprecated. this whole section is no more  
appropriate.

======================

   " Routing of global unicast prefixes outside the 6Bone range
    (3ffe::/16), and routing of global unicast prefixes yet undelegated
    in the range (3ffe::/16) are discussed in section 4, Routing
    policies, below.

MB: again, no more relevant. was really 6bone specific.

======================
    Global IPv6 addresses must be used for the end points of inter-site
    links. In particular, IPv4 compatible addresses MUST NOT be used for
    tunnels.

MB: ipv4 compatible were deprecated.

======================
3.10 6to4 Prefixes

    The 6to4 prefix, or some portion thereof, MAY be announced by any
    pTLA which has a current implementation of 6to4 in their IPv6
    network.  However, as 6to4 implementors gain more operational
    experience, it MAY be necessary to change this in some way.  At the
    time of the writing of this docuement, any pTLA MAY announce the  
6to4
    prefix into global EBGP. However, in order to announce this block,
    the pTLA MUST have a 6to4 router active, sourcing this prefix
    announcement.

    This section subject to change, and MAY vary, depending on 6to4
    progress within the NGTRANS working group.

MB: again, pretty old information, no more appropriate.

======================
3.11 Aggregation & advertisement issues

    Route aggregation MUST be performed by any border router talking EGP
    with any other IPv6 sites. More-specifics MUST NOT be leaked into or
    across the IPv6 6Bone backbone.

MB: if this advice is applied to current IPv6 "production" Internet,  
looks a bit like how the IETF wants the operators run their network.

======================
4. Routing Policies for the 6bone

    Leaf sites or pNLAs MUST only advertise to an upstream provider the
    prefixes assigned by that provider. Advertising a prefix assigned by
    another provider to a provider is not acceptable, and breaks the
    aggregation model. A site MUST NOT advertise a prefix from another
    provider to a provider as a way around the multi-homing problem.
    However, in the interest of testing new solutions, one may break  
this
    policy, so long as ALL affected parties  are aware of this test, and
    all agree to support this testing.  These policy breaks MUST NOT
    affect the 6bone routing table globally.

    To clarify, if one has two upstream pNLA or pTLA providers, (A and B
    for this example), one MUST only announce the prefix delegated to  
one
    by provider A to provider A, and one MUST only announce the prefeix
    delegated by one from provider B upstream to provider B. There  
exists
    no circumstance where this should be violated, as it breaks the
    aggregation model, and could globally affect routing decisions if
    downstreams are able to leak other providers' more specific
    delegations up to a pTLA. As the IPNG working group works through  
the
    multi-homing problem, there may be a need to alter this rule
    slightly, to test new strategies for deployment. However, in the  
case
    of current specifications at the time of this writing, there is no
    reason to advertise more specifics, and pTLA's MUST adhere to the
    current aggregation model.

======================
MB: again, it looks to me that this is really obsolete data.

    The peering agreements across the 6Bone may be by nature non-
    commercial, and therefore MAY allow transit traffic, if peering
    agreements of this nature are made. However, no pTLA is REQUIRED to
    give or receive transit service from another pTLA.

    Eventually, the Internet registries will assign prefixes under other
    than the 6Bone TLA (3FFE::/16). As of the time this document was
    written in 1999, the Internet registries were starting to assign /35
    sub-TLA (sTLA) blocks from the 2001::/16 TLA. Others will certainly
    be used in the future.

MB: again, it looks to me that this is really obsolete data.

======================
5. The 6Bone Registry

    The 6Bone registry is a RIPE-181 database with IPv6 extensions used
    to store information about the 6Bone, and its sites. The 6bone is
    accessible at:

          <http://www.6bone.net/whois.html>)

    Each 6Bone site MUST maintain the relevant entries in the 6Bone
    registry. In particular, the following object MUST be present for  
all
    6Bone leaf sites, pNLAs and pTLAs:

    -  IPv6-site: site description

    -  Inet6num: prefix delegation (one record MUST exist for each
       delegation)

    -  Mntner: contact info for site maintance/administration staff.

    Other object MAY be maintained at the discretion of the sites  
such as
    routing policy descriptors, person, or role objects.  The Mntner
    object MUST make reference to a role or person object, but those MAY
    NOT necessarily reside in the 6Bone registry. They can be stored
    within any of the Internet registry databases (ARIN, APNIC, RIPE- 
NCC,
    etc.)

MB: again, it looks to me that this whole section is really obsolete  
data.

======================
6. Guidelines for new sites joining the 6Bone

    New sites joining the 6Bone should seek to connect to a transit pNLA
    or a pTLA within their region, and preferably as close as  
possible to
    their existing IPv4 physical and routing path for Internet service.
    The 6Bone web site at <http://www.6bone.net> has various information
    and tools to help find candidate 6bone networks.

    Any site connected to the 6Bone MUST maintain a DNS server for
    forward name lookups and reverse address lookups.  The joining site
    MUST maintain the 6Bone objects relative to its site, as describe in
    section 5.

    The upstream provider MUST delegate the reverse address translation
    zone in DNS to the joining site, or have an agreement in place to
    perform primary DNS for that downstream. The provider MUST also
    create the 6Bone registry inet6num object reflecting the delegated
    address space.

    Up to date informatino about how to join the 6Bone is available on
    the 6Bone Web site at <http://www.6bone.net>.

MB: again, it looks to me that this whole section is really obsolete  
data.

======================
7. Guidelines for 6Bone pTLA sites

    The following rules apply to qualify for a 6Bone pTLA allocation. It
    should be recognized that holders of 6Bone pTLA allocations are
    expected to provide production quality backbone network services for
    the 6Bone.

    1. The pTLA Applicant must have a minimum of three (3) months
       qualifying experience as a 6Bone end-site or pNLA transit.   
During
       the entire qualifying period the Applicant must be operationally
       providing the following:

Rockell & Fink               Informational                      [Page 9]
RFC 2772           6Bone Backbone Routing Guidelines       February 2000

       a. Fully maintained, up to date, 6Bone Registry entries for their
          ipv6-site inet6num, mntner, and person objects, including each
          tunnel that the Applicant has.

       b. Fully maintained, and reliable, BGP4+ peering and connectivity
          between the Applicant's boundary router and the appropriate
          connection point into the 6Bone. This router must be IPv6
          pingable. This criteria is judged by members of the 6Bone
          Operations Group at the time of the Applicant's pTLA request.

       c. Fully maintained DNS forward (AAAA) and reverse (ip6.int)
          entries for the Applicant's router(s) and at least one host
          system.

       d. A fully maintained, and reliable, IPv6-accessible system
          providing, at a mimimum, one or more web pages, describing the
          Applicant's IPv6 services.  This server must be IPv6 pingable.

    2. The pTLA Applicant MUST have the ability and intent to provide
       "production-quality" 6Bone backbone service. Applicants must
       provide a statement and information in support of this claim.
       This MUST include the following:

       a. A support staff of two persons minimum, three preferable, with
          person attributes registered for each in the ipv6-site object
          for the pTLA applicant.

       b. A common mailbox for support contact purposes that all support
          staff have acess to, pointed to with a notify attribute in the
          ipv6-site object for the pTLA Applicant.

    3. The pTLA Applicant MUST have a potential "user community" that
       would be served by its becoming a pTLA, e.g., the Applicant is a
       major provider of Internet service in a region, country, or focus
       of interest. Applicant must provide a statement and  
information in
       support this claim.

    4. The pTLA Applicant MUST commit to abide by the current 6Bone
       operational rules and policies as they exist at time of its
       application, and agree to abide by future 6Bone backbone
       operational rules and policies as they evolve by consensus of the
       6Bone backbone and user community.

    When an Applicant seeks to receive a pTLA allocation, it will apply
    to the 6Bone Operations Group (see section 8 below) by providing to
    the Group information in support of its claims that it meets the
    criteria above.

MB: again, it looks to me that this whole section is really obsolete  
data.

======================
8. 6Bone Operations Group

    The 6Bone Operations Group is the group in charge of monitoring and
    policing adherence to the current rules. Membership in the 6Bone
    Operations Group is mandatory for, and restricted to, sites  
connected
    to the 6Bone.

    The 6Bone Operations Group is currently defined by those members of
    the existing 6Bone mailing list who represent sites participating in
    the 6Bone. Therefore it is incumbent on relevant site contacts to
    join the 6Bone mailing list. Instructions on how to join the list  
are
    maintained on the 6Bone web site at < http://www.6bone.net>.

MB: again, it looks to me that this whole section is really obsolete  
data.

======================
9.  Common rules enforcement for the 6bone

    Participation in the 6Bone is a voluntary and benevolent  
undertaking.
    However, participating sites are expected to adhere to the rules and
    policies described in this document in order to maintain the  
6Bone as
    a quality tool for the deployment of, and transition to, IPv6
    protocols and the products implementing them.

    The following is in support of policing adherence to 6Bone rules and
    policies:

    1. Each pTLA site has committed to implement the 6Bone's rules and
       policies, and SHOULD try to ensure they are adhered to by sites
       within their administrative control, i.e. those to who prefixes
       under their respective pTLA prefix have been delegated.

    2. When a site detects an issue, it SHOULD first use the 6Bone
       registry to contact the site maintainer and work the issue.

    3. If nothing happens, or there is disagreement on what the right
       solution is, the issue SHOULD be brought to the 6Bone Operations
       Group.

    4. When the problem is related to a product issue, the site(s)
       involved SHOULD be responsible for contacting  the product vendor
       and work toward its resolution.

    5. When an issue causes major operational problems, backbone sites
       SHOULD decide to temporarily set filters in order to restore
       service.

MB: again, it looks to me that this whole section is really obsolete  
data. Moreover, this is way out of scope for Ipv6 "production" Internet.

MB: did I convince you that RFC2772 is no more applicable and  
appropriate?