[16NG] Re: Review of the ipv6-over-ipv6cs draft

Some responses inline,

On Wed, 31 Jan 2007, Basavaraj Patil wrote:
>> The design implications of raising RA intervals (intead of, say, filtering
>> extra RAs out) may not be fully understood.  How are other protocols (e.g.,
>> periodic MLD reports, Neighbor Solicitations due to port scanning or
>> pinging
>> the all nodes multicast address, etc.) handled?
>
> Filtering extra RAs is not an option. The MS expects an RA at
> MaxAdvIntervals and filtering them would disrupt MS behavior.

Which implementations expect this?  Is this behaviour related to DNA? 
At least I have not seen this kind of dependency but I have a very 
limited view of fixed hosts only.  Host implementations that I'm aware 
of just look at the lifetimes of PIO options (can be long) for address 
lifetimes and AdvDefaultLifetime (max 9000sec) for default route 
lifetime.

Even if a default route would be lost while in suspend, I don't see 
this as an issue as immediately when the host gets woken up, the 
default route could be re-obtained by a) specific RA (if wake up call 
was sent by the AR -- at the same time or 20ms later) or b) a RS (if 
host decided to wake up).  Later you also said that when a host gets 
paged it needs to establish the link, implying that in fact there is 
some delay before link can be used after paging.

> The MS and AR are connected via a PtP link which is created via a
> combination of the transport connection over the air interface and a
> corresponding GRE tunnel between the BS and AR. Are there specific
> issues w.r.t MLD reports etc. on a PtP link that you believe need to
> be clarified?

I don't see PtP specific issues, except that MLD specifications expect 
that hosts send periodic MLD reports about the groups they have joined 
(including the solicited-node link local addresses).  Similarly, 
router is required to send MLD queries periodically on the link to 
check the multicast group memberships.  How are you going to deal with 
this scenario?  Will it require a protocol modification as well?

Are there other protocols similar to ND and MLD which require 
periodical messaging that may be relevant in this scenario (I can't 
recall from the top of my head, but I'd suspect there may be, whether 
standardized or proprietary)?

>> ==> However, if the MS is a router, RA is basically ignored in this kind of
>> context.  Hence, this approach of non-default MTU configuration seems
>> applicable between host and a router only.
>
> Okay... Do you have any suggestion or text that would help in this
> context?

I'm not sure which specific text would be most helpful here, but you 
should probably point out that the proposed approach is only 
applicable in host-router scenarios so you can't depend on it for all 
cases.  In other scenarios, other mechanisms (unfortunately, the only 
option I can think of is manual configuration at both ends) needs to 
be used.

>> How do you deal with periodic MLD reports, for
>> example?
>
> So what would break if periodic MLD reports are not sent.

If there is MLD snooping (to restrict multicast flooding) along the 
path, it will break.  I'm not sure how applicable this is in this 
context; if each MS (from the perspective of AR) has a separate link 
so that 10 multicast recipients of the same group would require 10 GRE 
tunneled packets (no optimization), this is maybe not an issue except 
for expandability.

I think this is more of a procedural issue, i.e., what steps are 
required to standardize a mechanism that breaks existing standardized 
mechanisms?  Do all the existing mechanisms need to be changed (first) 
or something else?  Should this approach be reviewed by the people who 
standardized the old mechanisms?

>> How do you prevent frequent port scanning from waking up the host
>> every 5 minutes when the router wants to do Neighbor Solicititation for the
>> address?
>
> It does not make sense to do wake up the host every 5 mins. Is there a
> reason for the AR to do NS periodically?

No -- unless AR has packets to send to the MS.

>> 3) The text above seems technically incorrect.  The key point here is what
>> is the MTU on the wired link between BS and AR.  If it supports MTUs higher
>> than 1500 (for example, GE jumboframes, SDH, ATM, whatever), tunneling
>> could
>> possibly still be used.
>
> True... But the fact is that for WiMAX, the profile specifies a MAX
> SDU of 1522 octets. So the packets on the air-interface cannot be
> greater than 1522 bytes. So the existence of links with higher MTU
> capability on the link between the BS<->AR does not matter.

We may be talking past each other, because I don't see what 
air-interface has to do with this (I'm assuming that the interface 
between AR and BS is _not_ air-interface but I may be wrong).  A 
1500-byte packet on AR-BS interface could be encapsulated in GRE 
(resulting in ~1550 byte packet or something like that) between AR and 
BS.  If AR-BS interface supports MTU higher than about 1550, this 
should be no problem.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng