The Routing Over Large Clouds Mailing List Archive by date

[David Horton <horton@citr.uq.oz.au>]

We have a number of questions about NHRP draft 7 based on our
implementation plans. We also have some suggestions for the MIB. 

David 
(+ RobC, RossB and SteveW)

===============================
Destination protocol address in register

We have a question about the processing of the Destination 
Protocol Address in Register Request/Reply Packets.

The field was added at nhrpv06, with text describing its usage 
added to nhrpv07.

 >
+>   Destination Protocol Address
+>     This is the protocol address of the NHS for which the source NBMA
+>     next hop information is being registered.
 >
 >   This packet is used to register a station's Protocol and NBMA
 >   addresses with its NHSs, as configured or known through conventional
 >   routing means.  This allows static configuration information to be
 >   reduced;  the NHSs need not be configured with the identities of all
+>   of the stations that they serve.  If an NHS receives an NHRP
+>   Registration Request packet for a station that it does not serve and
+>   that packet has a Destination Protocol Address which is not the
+>   protocol address of the NHS that is currently inspecting the packet
+>   then the NHS inspecting the packet MUST forward the registration
+>   along the routed path to the Destination Protocol Address.
 >
 >   It is possible that a misconfigured station will attempt to register
 >   with the wrong NHS (i.e., one that cannot serve it due to policy
 >   constraints or routing state).  If this is the case, the NHS MUST
 >   reply with a NAK-ed Registration Reply of type Can't Serve This
 >   Address.

The descriptive text does not cover all cases: what does a NHS do if
it recieves a register from a host it serves, but the host has set the
Destiantion Protocol Address field to something other than the address
of this NHS?

Effectively, this means that the NHS is configured to serve the host,
(so we are not in a mobility situation) 
but the host thinks it should be talking to somebody else. 

Should we forward to the address contained in the Destination Protocol 
Address field ? The only time I can think of this being useful is if
a host wants to register with a specific NHS but there are > 1 NHSs 
in the LIS. This situation still seems undefined at the moment.

The most robust solution would appear to be to accept the register,
send a registration reply with the corrected Destination Protocol Address
to the host, and also forward the register along.  This raises some
messy cache considerations though, and the client might crap itself if
it gets two registration replies for the one register.

We are currently leaning towards accepting the register, returning the
corrected Dest. address, and not forwarding the packet.   A suitable
message could be logged indicating that there is a mis-configuration
at the host or NHS.

On sending, is it reasonable and valid to have an empty Destination 
Protocol Address? (If the station were configured with only the
NBMA address of the NHS, perhaps an ATM anycast address, then it
may not know the destination protocol address of the NHS).

When responding, is it reasonable and valid for the NHS to fill 
in its protocol address. 

===============================
Omitted Error codes

A couple of error codes from earlier drafts have now been omitted
in the current draft. I can envisage cases where these codes could
still be applicable. What was the reasoning behind their removal?

(6) Server Unreachable
e.g. an NHS may need to forward a request to an adjacent router, but the 
link has just failed. (This is a bit contrived, and probably should be
solved at the IP routing level instead, but still it would allow
a previous NHS to retry the NHRP request forward down a different 
routing path).

(7) Protocol Error
e.g. a malformed packet such as a length mismatch, or
     a address family, or network layer protocol type not supported by the NHS

(Also there is the type code incorrectly listed as 6 instead of 7 in section
5.2.7  NHRP Error Indication)


===============================
MTU in register

I was wondering if the MTU could be included in the registration request
packet (in the same unused slot as used for the NHRP resolution reply).

I presume the value that would otherwise be used would be that configured
as the MTU for the IP subnet of the host if on the NBMA network (at that 
last NHS), or at the NHS/router if the target is off the NBMA network.

===============================
Explicit inclusion of LLC SNAP encapsulation into draft

Should Andy's mail of 28-Nov be incorporated into the text :-

> To: rolc@nexen.com, ip-atm@matmos.hpl.hp.com
> cc: malis@nexen.com
> Subject: New "Assigned Numbers" text for IANA SNAP Protocol IDs
> Date: Tue, 28 Nov 1995 14:22:16 -0500
> From: "Andrew G. Malis" <malis@nexen.com>
> 
> I can now report successful completion of an outstanding action item
> of mine for both the ROLC and IP/ATM working groups - the text below
> is now a part of the electronic version of "Assigned Numbers", and
> will be included in the next RFC version.  If you check out
> ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers, you'll
> see the new text near the end of the section.  I worded and formatted
> it for consistency with other Assigned Numbers text.
> 
> Andy
> -------
> SNAP PROTOCOL IDS IN THE IANA ETHERNET ADDRESS BLOCK
> 
> The Sub-Network Access Protocol (SNAP) header contains 40 bits: 24
> bits containing an IEEE-assigned Organizationally Unique Identifier
> (OUI), and 16 bits containing a Protocol Identifier (PID).  The OUIs
> are the same as those used in the Ethernet Vendor Address Components
> list below.  The IANA's OUI, 00-00-5E, may be used in SNAP headers
> with the appropriate PID to identify the protocols listed below.
> 
> Note that the IANA restricts this list to protocols that are ONLY
> identified in this manner; if a protocol has an EtherType, then SNAP
> headers identifying that protocol must contain an OUI of 00-00-00,
> with the EtherType in the PID field.
> 
> The SNAP PID assignments using the IANA's OUI are:
> 
> Protocol ID      Description                     References
> -----------      -----------                     ----------
> decimal  Hex      
>   0001   0001    MARS Data Messages (short form) [work in progress]
>   0002   0002    reserved for future NHRP use    [work in progress]
>   0003   0003    MARS/NHRP Control Messages      [work in progress]
>   0004   0004    MARS Data Messages (long form)  [work in progress]

===============================
NHS on boundary with 2 NBMA ID

In the situation where an NHS is on boundary of 2 NBMA 
networks (different IDs), and is acting as the NHS for LAGs in 
both networks, the wording in 5.3.2 NBMA Subnetwork ID extension 
is open to the misinterpretation that the NHS can return the address 
of device in the adjacent NBMA net (and LAG) because the NHRP packet 
itself is not crossing the boundary.

Is this worth tightening up?

===============================
Extension length processing

5.3.1 Destination prefix length
extension length of prefix is 1 octet but diagram shows 2 octets.


5.3.3 Responder address extension
extension length for responder address extension should be "variable" NOT "4"!

5. NHRP Packet Formats
The third paragraph of the section says :-
>        ...The length of the Extensions Part is implied by ar$pktsz minus
>        ar$extoff minus 20. 

        shouldn't it simply be:

                ar$pktsz minus ar$extoff

Do we inconsistent uses of offsets and sizes within the protocol?

===============================
Authentication type (+ authentication model)

In 5.3.7  NHRP Authentication Extension, believe we need to have 
an additional Authentication Type field for "none".

The case I am thinking of is a NBMA containing 3 LAGS, A-B-C.
Say a host in LAG-A, makes a request for the address of a host in C.
Further say the routing path goes A->B->C, and that LAGs A and C
both have authentication enabled, but LAG B doesn't.

So, the request from A will have an authentication extension.
When the NHS between B and C forwards the request into C, again
there needs to be an extension. From my understanding of the
extension processing, there needs to be an authentication 
extension in the packet through B, since there was one in
the original packet. Now, what should be the re-generated hop-by-hop
authentication inserted at the NHS between A and B?

The two options I see are to just copy the one from LAG-A, or
to have an explicit "no authentication data" type.
The latter would be my preferred option.

Is anyone able to provide an explanation of the authentication model
that NHRP is intending to use. I base my understanding along
the lines of that described in the MIB, which is subnet by subnet 
configuration.

I am a bit confused about how to apply point (c) at the bottom 
of page 6 of NHRP-7 (in section 2.2). :-

>     [Note: An Next Hop Resolution Reply can be returned directly to the
>     Next Hop Resolution Request initiator, i.e., without traversing the
>     list of NHSs that forwarded the Next Hop Resolution Request, if all
>     of the following criteria are satisfied:
>
>       (a) Direct communication is available via datagram transfer
>           (e.g., SMDS) or the NHS has an existing virtual circuit
>           connection to the Next Hop Resolution Request initiator or is
>           permitted to open one.
>       (b) The Next Hop Resolution Request initiator has not included the
>           NHRP Reverse NHS record Extension (see Section 5.3.5).
>       (c) The authentication policy in force permits direct
>           communication between the NHS and the Next Hop Resolution
>           Request initiator.

Does this mean that an NHS in a LAG at one side of a large cloud
needs to know the authentication configuration of a LAG on the other side?

===============================
NBMA-ID configuration in MIB.

How/when do you define multiple NBMA IDs. The NHRP extension allows
for multiple NBMA-IDs to be inserted by the first NHS. How does it
know which ones to put in? 

For the case where there is to always to be one ID inserted, then it
puts in the NBMA-ID configured for the subnet from which the NHRP
request came.  In the case where an NHS is the router between two NBMA
clouds, then I presume that any request stops at the NHS, and it returns
its own ATM(/NBMA) and IP address as the next hop.

If there are multiple NBMA-IDs for different LAGs/subnets at a particular
NHS, and we want to allow cut-throughs between these two clouds
(because merging/splitting), then I presume it could put in the
NBMA-IDs applicable to all the LAGs it knows of. But this only
works at the NHS at the boundary, not for an NHS interior to either
cloud. What is the configuration model for this case?

===============================
References
>   [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh
>       Govindan, draft-ietf-rolc-nbma-arp-00.txt.

Shouldn't this be RFC 1735 instead of draft-ietf-rolc-nbma-arp-00.txt?

===============================
NHRP-MIB

There have been a number of changes to the protocol since the
MIB was designed. I think some changes are needed.

Since server mode has gone, the nhrpIfForwardMode should be removed.

In the nhrpAddr table, I think we need some additional attributes:-
nhrpAddrNextHopNetAddr	(IpAddress)
nhrpAddrDestLinkSubAddr	(AtmAddress, or octet string?)
nhrpAddrLinkAddrType	(an enum based on Address Families, or an integer)
nhrpAddrMTU		(integer 0..65535)

In the nhrpStats table, some additional counters may be needed for 
completeness and symmetry. Perhaps the counters for the error
codes that are no longer in NHRP could be removed. 
The additions we suggest are:

nhrpStatsRequestForwards
nhrpStatsRegisterForwards
nhrpStatsInPurges
nhrpStatsOutPurges
nhrpStatsOutNegativeReplies
nhrpStatsInvalidExtensions
nhrpStatsInvalidReplies
nhrpStatsUnsupportedProtocols		Messages with a network protocol 
					of other than IPv4

=============================================================================
 David Horton
 Centre for Information Technology Research
 Level 2 South Tower, 339 Coronation Drive, Milton, Australia 4064
 Email: d.horton@citr.uq.oz.au       Phone +61 7 32592222   Fax +61 7 32592259