In your previous mail you wrote:
[Phil suggested I add mobileip back which was
dropped somewhere along the way]
I'm not sure we're communicating, so let me be a little
more explicit with what I had in mind:
1) MN arrives on new AR
=> many (academic or R&D) sites I know don't use firewalls
(they use a router for filtering) but have a passive management box
which detects new addresses and builds a database with MAC, IP,
name, location, etc, something very useful in case of problems.
So even if classical network access control is not performed on 1)
at the first packet, unusual behaviors are detected (i.e. there is
a passive and without automatic reaction kind of network access control).
At the opposite I know some (commercial) ISPs which use the (traditional)
network access control to punch holes in the firewall for outbound
traffic, i.e. all source addresses are blocked by default and
network access control is used to open some of them (in AAA term
the authorized resource is the Internet access): this is ingress
filtering at the address level, usually it is done at the access
device (e.g. modem) level too.
2) It sends a packet using its home address as the
*source* address -- no HAO at all.
=> I propose that the packet is sent to the home agent (or something
similar).
3) AR recognizes that the source address is not one of
the subnets it subtends and sends an ICMP message
to MN which explains the problem
=> perhaps I should add a statement in the draft with a requirement
(modulo ICMP rate limitation) for ICMPs when a HAO is filtered out.
I believe a router should implement this by default but a detailed
text should help.
What ICMP? I propose 4 (Parameter Problem) - 2 (unrecognized IPv6 option),
as the router is not the destination of the packet the MN should
understand what's happened. Note that 1 (Destination Unreachable) -
1 (administratively prohibited) is too ambiguous.
4) MN sends AR a normal CN binding update
=> 4) is what I consider as a kind of network access control.
5) AR lifts the restriction for that source address
=> the difference with my proposal is here, I propose to accept
corresponding HAOs, you propose to directly open the ingress filtering.
See more comments after.
6) MN now sends packets as in (2), but unimpeded
If MN knows that there is likely to be a source
address check on AR, it can delete steps 2 and 3.
=> i.e. active/reactive modes.
ICMP seems like a natural here because the router
really is reporting a network problem back to MN
(or not MN if a host were incorrectly configured,
etc).
=> in any case ICMP errors have to be sent when packets are dropped,
I believe we can reach a consensus about this very quickly.
If this is a subset of your proposal, fine. It
does seem that what I propose gets rid of the HAO
altogether which you don't seem to agree with.
=> in order to get rid of the HAO your proposal has to be
supported on every ingress filtering devices where a packet
from the MN can go though. This is not in fact like path MTU
discovery (which is already difficult to get in the real world)
because your proposal uses a signaling with all the usual
problems of signaling (scalability, security, ...).
Even if to get rid of the HAO would be very nice, I don't
believe this will work in practice. To summary this has the
same kind of problems (i.e. limitations) than micro-mobility
(i.e. mobility based on host routing).
However, may I suggest that it's the AAA part that
=> I insist about AAA: AAA is not an essential part of
my proposal, it only brings extra goodies:
- an instance of network access control which is well known
and already has proposed extensions for (mobile) IPv6
- remote network access control
- a connection between local and remote access control.
has become the lightning rod? And that maybe it
shouldn't be quite so ambitious? :-)
=> too ambitious for a global deployment, and for local/special cases
I am afraid that micro-mobility is more attractive (it gets rid
of the routing header too).
Regards
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
