The Routing Over Large Clouds Mailing List Archive by date

[James Luciani <luciani@nexen.com>]

> ===============================
> 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?
I see your point.  This text was added in response to the NEC proposal.
The field allows the NHRP packet to follow the routed path in a Request.
All that aside, yes... there is an ambiguity.  In the scenario you 
just described, NHSs forward the packet.  The packet should follow the
routed path to the Dest Proto Addr at which point if the Dest "serves" the 
client then all is as expected otherwise an NHRP Registration Reply NAK is
sent to the source proto addr with a NAK code "4 - Can't Serve This Address".
Does that clear this up?  At this point you cannot forward the the request
off the cloud so if the packet reaches an egress router then a NAK is sent
back from the egress router/NHS.
> 
> On sending, is it reasonable and valid to have an empty Destination 
> Protocol Address? (If the station were configured with only the
NO.  The rule is exactly this: A request/indication follows the routed path to the
destination proto addr (or until an error occurs) and a reply follows
the routed path back to the source proto addr (and should deliver the packet
through the source NBMA interface as well).
> NBMA address of the NHS, perhaps an ATM anycast address, then it
Until we have UNI 4.0 we cannot talk about ATM anycast in NHRP.
> 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. 
Now you are in a gray area and to be honest if it is "your NHS and
your NHC" then it really does not matter as long as you fix the
checksum.


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

> (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).
This can be handled a number of ways.  However, I have no objection to adding
this in a more general form such as:"6-Protocol Address Unreachable".

> (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
Agreed.

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

> ===============================
> 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 have no problem with this.

> ===============================
> Explicit inclusion of LLC SNAP encapsulation into draft
> 
> Should Andy's mail of 28-Nov be incorporated into the text :-
I would say no because NHRP and MARS have not yet merged into one protocol
and will not until v2 of NHRP or beyond.  I also think this text would serve
to confuse people since it talks about many non-applicable points to NHRP.

> ===============================
> 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.
I don't see that but I will be more wordy to make sure that noone else
sees it.

> ===============================
> Extension length processing
> 
> 5.3.1 Destination prefix length
> extension length of prefix is 1 octet but diagram shows 2 octets.
Fixed.

> 5.3.3 Responder address extension
> extension length for responder address extension should be "variable" NOT "4"!
Hey! I knew there'd be a lousy IP centric reference left over no matter
how hard I tried to remove them. :-)  Done..

> 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
This was already noted but good catch anyway.

> ===============================
> 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). :-
Personally, I think this section should be removed.  It is, in fact, 
directly opposing MPOA's needs but heh...
> 
> >     [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).
I think the deal here is that the access control filters at the NBMA level
must permit the direct communication.  This is not really "authentication" though.
I do not know what the original writer of this section meant to be honest but
that is how I interpreted it (potentially naively).
> >       (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?
Based on what I said earlier, the answer is yes in a sense.
A given filter in LIS A could say that I will not except traffic from LIS B
unless it flows through router R.  If you support filters of this kind then
this is an issue.

FYI... Like I said, I think this section should be removed.  Also, I am not
a security guy so maybe someone out there can enlighten me of other 
interpretations of (c).


> ===============================
> NBMA-ID configuration in MIB.
> 
> How/when do you define multiple NBMA IDs.
When you want multiple administrative NBMA domains within a single 
NBMA physical domain (e.g., multiple logical ATM networks within
a single signaling domain).  

>  The NHRP extension allows
> for multiple NBMA-IDs to be inserted by the first NHS. How does it
> know which ones to put in? 
Another example...  A single IP subnet
need not be completely contained within a single signaling domain;
there are some substantial difficulties but such a case occurs when
a public NBMA network is sandwiched between two private NBMA networks 
and there are IP nodes on the same subnet in both private NBMA networks.
IMHO, each network interface should be configured with its NBMA Subnetwork ID.

> 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?
IMHO, you are creating a scenario which is contrary to the purpose of
the ID.  In terms of the configuration model, that is administration specific
by design.  The applicable section is below:
**  5.3.2  NBMA Subnetwork ID Extension
**  
**      Compulsory = 1
**      Type = 2
**      Length = variable
**  
**     This extension is used to carry one or more identifiers for the NBMA
**     subnetwork.  This can be used as a validity check to ensure that an
**     NHRP packet does not leave a particular NBMA subnetwork.  The
**     extension is placed in a "request" packet with an ID value of zero.
**     The first NHS along the routed path fills in the field with the
**     identifier(s) for the NBMA subnetwork.
**  
**     Multiple NBMA Subnetwork IDs may be used as a transition mechanism
**     while NBMA Subnetworks are being split or merged.
**  
**            0                   1                   2                   3
**            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
**           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
**           |                    NBMA Subnetwork ID                         |
**           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
**                                       ...
**  
**     Each identifier consists of a 32 bit globally unique value assigned
Please note the following two sentences especially:
**     to the NBMA subnetwork.  This value may be chosen from the
**     internetworking layer address space administered by the operators of
**     the NBMA subnetwork if such an address can fit into a 32 bit field.
**     This value is used for identification only, not for routing or any
**     other purpose.

> 
> ===============================
> 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.
We will look at these. Thanks.

> 
> 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
> 
> =============================================================================