Subject: Re: [netlmm] comments on draft-ietf-netlmm-pmip6-ipv4-support-02

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 5 Mar 2008 08:21:01 -0800 (PST)

Julien, while I agree that similar solution is both possible and should be looked for, I think that we should consider the probability of these skewed cases to happen. A collision on link-local addresses could mainly occur because of MAC address collision which is a 48/64 bit domain. 
However IPv4 private address collision as explained here:
It 
may 
happen 
that 
the 
LMA 
assigns 
the 
address 
x 
to 
the  
MN 
and 
that 
this 
same 
address 
is 
used 
by 
the 
MAG 
as 
its 
own 
address  
(on 
the 
interface 
facing 
the 
MN)
IPv4 address collision amounts to a much smaller (less than 32 bit) domain.
  So I would argue that IPv4 address collision probability is higher.

Regards,

Behcet
----- Original Message ----
From: Julien Laganier <[email-masked]>
To: "Premec, Domagoj" <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, March 5, 2008 8:59:29 AM
Subject: Re: [netlmm] comments on draft-ietf-netlmm-pmip6-ipv4-support-02

Domagoj,

On 
Wednesday 
05 
March 
2008, 
Premec, 
Domagoj 
wrote:
Julien,
Yes, 
it 
makes 
sense 
to 
allow 
MAGs 
to 
use 
private 
IP 
addresses. 
IMO 
it
also 
make 
sense 
not 
to 
force 
MAGs 
to 
use 
the 
collision 
avoidance
mechanism 
if 
they 
are 
using 
public 
IP 
addresses. 
We 
can 
leave 
it 
up
to 
a 
deployment.

Right, 
the 
collision 
avoidance 
mechanism 
can 
be 
skipped 
whenever 
a 
MAG 
has 
a 
public 
IPv4 
address.

Since 
in 
the 
v4 
case 
the 
MN 
rely 
on 
DHCP 
for 
address
allocation, 
the 
default 
router 
can 
be 
configured 
as 
part 
of
DHCP 
as 
well. 
Thus 
I'm 
not 
sure 
it 
makes 
sense 
to 
use 
v4
router 
advertisement 
in 
NETLMM.
The 
unmodified 
IP 
host 
is 
free 
to 
send 
the 
v4 
RS 
anytime 
it 
wants, 
we
can't 
tell 
the 
host 
not 
to 
use 
it. 
RS/RA 
exchange 
is 
also 
related 
to
the 
default 
router 
cache 
at 
the 
MN 
and 
how 
it 
gets 
updated 
as 
the 
MN
moves 
across 
MAGs. 
We 
don't 
assume 
the 
MN 
will 
initiate 
DHCP 
when
there 
is 
a 
link 
change.

The 
MAG 
just 
discard 
the 
v4 
RS. 
A 
host 
can't 
assume 
v4 
router 
discovery 
is 
deployed 
everywhere. 
The 
default 
router 
cache 
will 
be 
updated 
by 
DHCP. 
A 
host 
should 
do 
DHCP 
when 
there's 
a 
link 
change, 
otherwise 
it 
gets 
into 
trouble 
whenever 
handover 
occurs 
from 
one 
link 
to 
another. 
If 
the 
host 
doesn't 
do 
DHCP 
then, 
that's 
the 
problem 
of 
the 
host, 
not 
of 
DHCP. 
For 
a 
host 
to 
work 
well 
in 
a 
mobile 
environment, 
it 
needs 
to 
implement 
DNAv4 
(aka 
RFC4436). 
If 
that 
is 
the 
case, 
the 
host 
will 
conclude 
it 
changed 
link 
since 
ARP-based 
reachability 
tests 
with 
the 
previous 
router 
will 
fail, 
and 
DHCP 
will 
kick 
in. 

--julien

-----Original 
Message-----
From: 
julien 
laganier 
[mailto:[email-masked]] 
On
Behalf 
Of 
Julien 
Laganier
Sent: 
05. 
ožujak 
2008 
15:05
To: 
[email-masked]
Cc: 
Premec, 
Domagoj
Subject: 
Re: 
[netlmm] 
comments 
on
draft-ietf-netlmm-pmip6-ipv4-support-02
Premec,
On 
Wednesday 
05 
March 
2008, 
Premec, 
Domagoj 
wrote:
Julien,
I 
agree 
that 
the 
collision 
of 
private 
IPv4 
addresses 
between 
MN
and 
MAG 
is 
similar 
to 
the 
IPv6 
link-local 
address 
collision
described 
in
the 
baseline 
spec. 
I'm 
fine 
with 
eihter 
solution 
(v6-like
mechanism 
for 
collision 
avoidance 
or 
public 
addresses 
on 
MAG).
I'd 
prefer 
the 
former 
since 
it 
doesn't 
unnecessarily 
restrict
deployments. 
Also, 
given 
the 
scarcity 
of 
public 
IPv4
addresses 
these 
days, 
and 
given 
that 
the 
MN-facing 
MAG 
IPv4
address 
is 
used 
for 
nothing 
else 
than 
a 
placeholder 
in 
the
MN's 
routing 
table, 
I 
think 
this 
is 
definitely 
a 
good 
choice
to 
allow 
for 
private 
IPv4 
addresses 
as 
MN-facing 
MAG 
address.
The 
MAG 
does 
not 
send 
packets 
to 
the 
MN 
over 
IPv4 
before 
it
retrieves 
the 
MN's 
(possibly 
private) 
HoA.
I 
wonder 
if 
this 
is 
always 
the 
case. 
v4 
Router 
Advertisment
does 
not
carry 
any 
MN 
specific 
info, 
could 
it 
be 
sent 
(possibliy 
in
a 
response
to 
RS) 
even 
before 
the 
PBU/PBAck 
exchange 
is 
completed? 
We 
should
probably 
explicitely 
say 
that 
MAG 
is 
not 
allowed 
to 
send
anything 
to
the 
MS 
before 
it 
gets 
PBAck.
Since 
in 
the 
v4 
case 
the 
MN 
rely 
on 
DHCP 
for 
address
allocation, 
the 
default 
router 
can 
be 
configured 
as 
part 
of
DHCP 
as 
well. 
Thus 
I'm 
not 
sure 
it 
makes 
sense 
to 
use 
v4
router 
advertisement 
in 
NETLMM.
--julien
-----Original 
Message-----
From: 
julien 
laganier 
[mailto:[email-masked]]
On 
Behalf
Of 
Julien 
Laganier
Sent: 
05. 
ožujak 
2008 
10:42
To: 
[email-masked]
Cc: 
Premec, 
Domagoj; 
RYUJI 
WAKIKAWA
Subject: 
Re: 
[netlmm] 
comments 
on
draft-ietf-netlmm-pmip6-ipv4-support-02
Premec, 
Ryuji,
On 
Wednesday 
05 
March 
2008, 
Premec, 
Domagoj 
wrote:
Ryuji,
This 
issue 
can 
be 
also 
happened 
to 
the 
original 
DSMIP.
If 
HA 
provides 
a 
private 
HoA 
and 
MN 
obtains 
a 
private
CoA 
at 
the
visiting 
network, 
both 
addresses 
can 
be 
duplicated 
in 
some
scenarios...
yes... 
although 
the 
issue 
in 
DSMIP6 
does 
not 
affect 
the 
AR
(i.e. 
MAG). 
In 
DSMIP6 
it 
is 
the 
visited 
domain 
that 
allocates
both 
the 
CoA
and 
the 
AR's 
address, 
so 
there 
will 
be 
no 
collision. 
In
PMIP 
case 
the
MN's 
IP 
address 
comes 
from 
a 
different 
domain 
(LMA) 
and 
thus
it 
may 
collide 
with 
the 
MAG's 
address. 
However, 
in 
DSMIP6
case 
it
is 
possible
that 
there 
is 
CoA-HoA 
collision 
as 
they 
may 
be 
allocated 
by
different
administrative 
domains. 
Such 
collision 
is 
not 
visible 
to
the 
foreign
network, 
it 
only 
affects 
the 
MN.
The 
issue 
of 
collision 
of 
a 
private 
IPv4 
addresses 
of 
MN 
and
MAG 
looks 
similar 
to 
the 
issue 
of 
collision 
of 
IPv6
link-local 
addresses
of 
MN 
and 
MAGs.
For 
IPv6 
link-local 
addresses, 
one 
of 
the 
workaround 
is
for 
the 
MAG
to 
store 
the 
IPv6 
link-local 
addresses 
of 
the 
MN 
in 
the 
binding
cache 
entry 
at 
the 
LMA.
The 
MAG 
does 
not 
send 
packets 
to 
the 
MN 
over 
IPv6 
before 
it
retrieves 
the 
MN's 
IPv6 
HNP. 
Thus 
the 
MAG 
does 
not 
need
to 
have 
an
IPv6 
link-local 
address 
on 
the 
interface 
facing 
the 
MN 
prior 
to
receiving 
the 
IPv6 
HNP 
that 
comes 
together 
with 
the 
IPv6
link-local
of 
the 
MN.
Then 
the 
MAG 
can 
pick 
up 
for 
itself 
an 
IPv6 
link-local
that 
does 
not
collide 
with 
that 
of 
the 
MN, 
and 
send 
the 
RA.
One 
solution 
for 
this 
is 
to 
prohibit 
using 
a 
private 
home
address 
in
DSMIP.
I'm 
not 
sure 
whether 
this 
modification 
is 
acceptable 
or
not..
This 
seems 
a 
bit 
drastic. 
In 
PMIP 
case 
we 
could 
mandate
that 
MAGs 
must
be 
configured 
with 
public 
IP 
address 
on 
the 
interface
facing 
the
MN.
I 
don't 
think 
this 
is 
necessary.
If 
it 
is 
desired 
that 
the 
MAG 
use 
private 
IPv4 
addresses,
a 
solution
similar 
to 
the 
IPv6 
link-local 
workaround 
can 
be 
adopted, 
it's
nearly 
as 
simple 
as 
s/IPv6 
link-local/IPv4 
private/
:)
Thoughts?
--julien
_______________________________________________
netlmm 
mailing 
list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

_______________________________________________
netlmm 
mailing 
list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm