New Issues #22, #23, #24, #25, #26 and #27

Folks,

As a follow up to last weeks discussion on the MN-AR
interface draft, 
I've filled some issues along with proposed resolutions in
the 
tracker at tools.ietf.org (thanks Henrik!) Here are the
links and 
summaries of the issues:

Issue #22: Multicast IPv6 ND triggers do not provide MN with

confirmation of MAP registration success/failure.
<http://www1.tools.ietf.org/wg/netlmm/trac/ticket/22>

Issue #23: Multicast IPv6 ND triggers cause many ARs to send
UPDATEs 
when there are many ARs on the link.
<http://www1.tools.ietf.org/wg/netlmm/trac/ticket/23>

Issue #24: Setting MN/AR/MAP as DHCPv6 client/relay/server
fixes 
issues #22 and #23
<http://www1.tools.ietf.org/wg/netlmm/trac/ticket/24>

Issue #25: MN-AR interface specifying REDIRECT behavior
<http://www1.tools.ietf.org/wg/netlmm/trac/ticket/25>

Issue #26: link-local scoping in a NetLMM domain is
undefined
<http://www1.tools.ietf.org/wg/netlmm/trac/ticket/26>

Issue #27: Broken security procedure for DAD
<http://www1.tools.ietf.org/wg/netlmm/trac/ticket/27>

Best,

--julien
_______________________________________________
netlmm mailing list
netlmmngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm

Folks,

As a follow up to last weeks discussion on the MN-AR
interface draft, 
I've filled some issues along with proposed resolutions in
the 
tracker at tools.ietf.org (thanks Henrik!) Here are the
links and 
summaries of the issues:

Issue #22: Multicast IPv6 ND triggers do not provide MN with

confirmation of MAP registration success/failure.
<http://www1.tools.ietf.org/wg/netlmm/trac/ticket/22>

Issue #23: Multicast IPv6 ND triggers cause many ARs to send
UPDATEs 
when there are many ARs on the link.
<http://www1.tools.ietf.org/wg/netlmm/trac/ticket/23>

Issue #24: Setting MN/AR/MAP as DHCPv6 client/relay/server
fixes 
issues #22 and #23
<http://www1.tools.ietf.org/wg/netlmm/trac/ticket/24>

Issue #25: MN-AR interface specifying REDIRECT behavior
<http://www1.tools.ietf.org/wg/netlmm/trac/ticket/25>

Issue #26: link-local scoping in a NetLMM domain is
undefined
<http://www1.tools.ietf.org/wg/netlmm/trac/ticket/26>

Issue #27: Broken security procedure for DAD
<http://www1.tools.ietf.org/wg/netlmm/trac/ticket/27>

Best,

--julien
_______________________________________________
netlmm mailing list
netlmmngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm

Julien Laganier wrote:
> Issue #24: Setting MN/AR/MAP as DHCPv6
client/relay/server fixes 
> issues #22 and #23 
> <ngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm

Some comments on resolutions for issues #22 and #23:

> Issue #22: Multicast IPv6 ND triggers do not provide MN
with 
> confirmation of MAP registration success/failure.
> <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/22>

Agree with cases 1) and 2), but there is also another case:
3) AR fails to reach the MAP due to packet loss caused by
temporal congestion, signal intermittence, etc. In that
case, the AR has to wait for a timeout period before either
trying again or returning a false negative to the MN.

If the AR takes too much time in retrying, the MN will
wrongly conclude that its address has been registered with
the MAP and its communications using that address will go
into a black hole. If the AR returns a false negative (i.e.,
a solicited NA), the MN will wrongly conclude that its
proposed address is a duplicate. Neither of these anomalous
conditions would occur if MAP registrations were driven by
the MN itself instead of the AR, e.g., when the MN/AR/MAP
are configured as DHCP client/server/relay.   

> Issue #23: Multicast IPv6 ND triggers cause many ARs to
send UPDATEs 
> when there are many ARs on the link.
> <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/23>

The proposed solution assumes a NETLMM backbone protocol
in which potentially many ARs engage in a decision process
as to which one(s) should register the MNs address with the
MAP. Such a backbone protocol would need to be incredibly
well coordinated and agile. When the MN/AR/MAP are
configured
as DHCP client/relay/server there is no such backbone
protocol
required, since the MN itself selects which AR(s) to use.

Suggest reading and send comments on:

http://www.ietf.org/internet-drafts/draf
t-templin-autoconf-netlmm-dhcp-0
0.txt  

Fred
fred.l.templinboeing.com

_______________________________________________
netlmm mailing list
netlmmngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm

> Issue #25: MN-AR interface specifying REDIRECT behavior
> <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/25>

The proposed resolution may not be appropriate for all
media types. A better resolution would be to simply say:

 "See: (RFC2461(bis), section 2)."

Fred
fred.l.templinboeing.com

_______________________________________________
netlmm mailing list
netlmmngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm

Repost to include dhc wg; comments to the list:

Some comments on resolutions for issues #22 and #23:

> Issue #22: Multicast IPv6 ND triggers do not provide MN
with 
> confirmation of MAP registration success/failure.
> <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/22>

Agree with cases 1) and 2), but there is also another case:
3) AR fails to reach the MAP due to packet loss caused by
temporal congestion, signal intermittence, etc. In that
case, the AR has to wait for a timeout period before either
trying again or returning a false negative to the MN.

If the AR takes too much time in retrying, the MN will
wrongly conclude that its address has been registered with
the MAP and its communications using that address will go
into a black hole. If the AR returns a false negative (i.e.,
a solicited NA), the MN will wrongly conclude that its
proposed address is a duplicate. Neither of these anomalous
conditions would occur if MAP registrations were driven by
the MN itself instead of the AR, e.g., when the MN/AR/MAP
are configured as DHCP client/server/relay.   

> Issue #23: Multicast IPv6 ND triggers cause many ARs to
send UPDATEs 
> when there are many ARs on the link.
> <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/23>

The proposed solution assumes a NETLMM backbone protocol
in which potentially many ARs engage in a decision process
as to which one(s) should register the MNs address with the
MAP. Such a backbone protocol would need to be incredibly
well coordinated and agile. When the MN/AR/MAP are
configured
as DHCP client/relay/server there is no such backbone
protocol
required, since the MN itself selects which AR(s) to use.

Suggest reading and send comments on:

http://www.ietf.org/internet-drafts/draf
t-templin-autoconf-netlmm-dhcp-0
0.txt  

Fred
fred.l.templinboeing.com

_______________________________________________
netlmm mailing list
netlmmngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm

Fred,

On Thursday 11 May 2006 19:38, Templin, Fred L wrote:
> Repost to include dhc wg; comments to the list:

[ Not sure this is relevant to DHCWG list. Removed it. ]

> Some comments on resolutions for issues #22 and #23:

(snip)

> > Issue #23: Multicast IPv6 ND triggers cause many
ARs to send
> > UPDATEs when there are many ARs on the link.
> > <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/23>
>
> The proposed solution assumes a NETLMM backbone
protocol
> in which potentially many ARs engage in a decision
process
> as to which one(s) should register the MNs address with
the
> MAP. Such a backbone protocol would need to be
incredibly
> well coordinated and agile. 

I don't see anything incredible here; Do you mean it is
incredible to 
elect one entity out of a finite set?

> When the MN/AR/MAP are configured as DHCP
client/relay/server there
> is no such backbone protocol required, since the MN
itself selects
> which AR(s) to use. 

Two points here. 

1) Regarding the fact that no such protocol is required,
well the goal 
of that WG is no design a protocol anyway so I don't see
the point in 
avoiding to have one.

2) If such election is taken care in the backbone, still the
MN can 
select itself which AR to use. It will simply happen that
the MN will 
respectivelly send and receive packets from the AR _it_
selected, and 
from the AR elected in the backbone.

> Suggest reading and send comments on:
>
> http://www.ietf.org/internet-drafts/draft-tem
plin-autoconf-netlmm-d
>hcp-0 0.txt

I did. You seem to insist that "if DHCP is used
then..." 

What if DHCP is not used? (AFAIK, stateless address autoconf
is a MUST 
for IPv6, while stateful (DHCP) is only a MAY.) So I don't
think that 
DHCP is relevant to this issue.

So I still think that no text change is needed w.r.t. issue
#22. 
Anyone else with a different opinion?

--julien
_______________________________________________
netlmm mailing list
netlmmngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm

On Thursday 11 May 2006 19:38, Templin, Fred L wrote:
> Repost to include dhc wg; comments to the list:

[ Not sure this is relevant to DHCWG list. Removed it. ]

> Some comments on resolutions for issues #22 and #23:
> > Issue #22: Multicast IPv6 ND triggers do not
provide MN with
> > confirmation of MAP registration success/failure.
> > <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/22>
>
> Agree with cases 1) and 2), but there is also another
case:
> 3) AR fails to reach the MAP due to packet loss caused
by
> temporal congestion, signal intermittence, etc. In that
> case, the AR has to wait for a timeout period before
either
> trying again or returning a false negative to the MN.
>
> If the AR takes too much time in retrying, the MN will
> wrongly conclude that its address has been registered
with
> the MAP and its communications using that address will
go
> into a black hole. 

I fail to see how the situation you describe is specific to
NetLMM.

What if a plain host (not mobile, not in a NetLMM domain)
selects an 
AR, but it happens that because of "packet loss caused
by temporal 
congestion, signal intermittence, etc." that the IGP
on that AR does 
not run properly preventing it to deliver packets...

It would send to the MN a ICMP destination unreachable and
hopefully 
the MN would select another AR if there's one.

> If the AR returns a false negative (i.e., 
> a solicited NA), the MN will wrongly conclude that its
> proposed address is a duplicate. Neither of these
anomalous
> conditions would occur if MAP registrations were driven
by
> the MN itself instead of the AR, e.g., when the
MN/AR/MAP
> are configured as DHCP client/server/relay.

I already expressed my opinion about DHCP: What if DHCP is
not there? 
In the absence of DHCP, because our charter assume no host 
involvevement w.r.t. NetLMM how can the MN drive the MAP
registration 
itself?

It sends a NS (as part of DAD) or a RS (as part of DNA). I
said all of 
that already so I'll try to refrain from posting the same
arguments 
again here. If anyone else has an opinion please speak up.

--julien
_______________________________________________
netlmm mailing list
netlmmngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm