This write up captures the impact of flexing the one-hop requirement on the PANA
design.


	A- PAA discovery
	B- Multiple PAAs
	C- IP addressing
	D- TTL check
	E- NAT traversal


A- PAA discovery

  Issue: How does the PaC discover PAA if PAA is off-link?

  Alternative solutions considered:

  1- EP upon detecting PDI sent by a PaC can use EP-to-PAA protocol to trigger an 
     unsolicited PSR sent from the PAA. 

  This does not require any additional protocol work. PANA already supports
  this model (see "traffic-driven PAA discovery").


  2- Design a DHCP option for PAA discovery.

  This additional scheme can be pursued in DHC WG. 


B- Multiple PAAs

  Issue: If there are multiple PAAs in the access network, scattered
  all around, do we have a "selection" issue now? If it matters which
  PAA is selected, then we need to talk about that.

  Solution considered:

  It is the simplest (and yet still practical) to state
  that deployments using multiple PAAs should ensure it does not 
  matter which PAA is chosen for PANA. This is already stated in
  the base spec for multiple on-link PAAs. Same rule should apply
  to multiple off-link PAAs as well, hence there is no protocol
  change needed.

  Future PANA extensions (separate I-Ds) can describe a detailed 
  selection scheme, if necessary.
   
C- IP addressing

  Issue: If the PAA is off-link, a link-local PRPA is not suitable.

  Solution considered:
  
  Just state that, if a deployment is using off-link PAAs, it must
  ensure allocation of non-link-locals as PRPA. For example, it can
  allow global address configuration via DHCP, or stateless IPv6
  autoconfig before the PANA run. This is a deployment consideration,
  no protocol work needed.

D- TTL check

  Issue: If the PAA is off-link, we cannot rely on TTL check.

  Solution considered:

  We haven't required PAA be on-link because we needed this TTL
  check.  We (naturally) encoded this check in the design knowing that
  PAA is always on-link. 

  We can either drop the TTL checks, or use an adaptive scheme where
  TTL checks are enforced as soon as PaC and PAA knows the peer is
  on-link. PAA may already know whether PaCs are always on-link or not.
  PAA and PaC can inspect the first PANA packets to determine if the
  peer is on-link, and enforce the check on any subsequent PANA packet.


E- NAT traversal

  Issue: Now that PAA can be multiple hops away, there may be NATs
  between the PaC and PAA. Does this impact PAA discovery and integrity
  checks?
  
  None of the discovery schemes in [A] are impacted by NATs. 

  Next revision of the spec will discontinue source IP/MAC headers 
  comparison with the DI payload. Therefore, there is no longer any 
  issues here.