John,
I would prefer all requirements for me to implement are in the specs as a programmer.
I view node reqs doc as a statement of further reqs of the std regarding conformance
not implementation. If we don't want HAO to be MUST make it a SHOULD this should be
decided in the MIPv6 spec.k
HAO SHOULD be implemented. MUST is a stretch and I always thought so since draft 1.
The security argument is irrelevant to being a MUST or SHOULD if I deployed MIPv6 I
would not use RR or any IPsec there are many ways to secure the mobile nodes and CNs
and I agree with Vijays point on this
Given that there is no documented method to do stateless HAO
verification, I believe it's extremely premature to make HAO a MUST.
- Bill
IETF IPng Working Group Mailing List
IPng
Kuntal Chowdhury wrote:
Here are two of the reasons why I think RO will be undesirable:
There might be reasons at some situations to not do RO. But
the spec already allows for that, either by the decision of the
MN or the CN.
So, we can cover the situations that you list, whether or not
your
Glenn Morrow wrote:
I thought it was already decided that a CN MUST respond with a rate
limited lack of resources response to the request for route
optimization.
Yes!
If this is the case then it seems to follow that the
processing of the HOA for this purpose MUST also be supported if
[EMAIL PROTECTED] wrote:
RO gives you the capability of having two end-points connected without
having to rely on intermediate nodes such as the HA being
involved. The HA is not the bottleneck. One of the benefits of RO is
lesser traffic in the backbone and to a certain degree reduced
HAO is not useful without verification and largely pointless unless
you're doing route optimization and can support a binding cache which
is large enough to be meaningful.
the point is this verification can be done in many ways.
Vijay,
I don't think any of these many ways are MUST
Title: RE: [mobile-ip] Re: HAO and BE processing will be mandated
I agree - let's move on.
-Original Message-
From: Jari Arkko [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 23, 2002 3:25 AM
To: Morrow, Glenn [RICH2:C310:EXCH]
Cc: Michael Thomas; [EMAIL PROTECTED]; [EMAIL
I also think the current installed IPv6 base is going to be
*insignificant* compared to the IPv6 base that is expected.
yes. and the V4 base is growing fast too. so?
the question is what works best. it would be good if we
focussed on that.
randy
I am of the opinion that the scale of IPv6 deployment today is still
in its infancy and the impacts associated with mandating the HAO
processing on all IPv6 nodes is far less than maybe two years from
now.
here are a little (incomplete) list of RFC2460-compliant
implementations
I am of the opinion that the scale of IPv6 deployment today is still
in its infancy and the impacts associated with mandating the HAO
processing on all IPv6 nodes is far less than maybe two years from
now.
Is that the point?
My point was that the support of binding exchange and binding cache
but I keep hearing from the KAME folks again and again
we already have IPv6 implementations which do not understand
HAO, we dont want HAO mandated (which makes no sense to me).
MUST for HAO is self-contradictory at best. if HAO is a MUST, we don't
need bidir-tunnel (since it
I've been using KAME code since August 1999 when I patched FreeBSD 3.4
to support IPv6. I think the community owes a great debt to all the
KAME developers, without whose work we probably wouldn't have as great
an installed BSD IPv6 base as we do.
So I mean no disrespect to the KAME developers
thanks Phil. this approach sounds good.
Vijay
Phil Roberts wrote:
Folks,
this discussion doesn't seem to be going anywhere at the point. Perhaps
we
can drop it?
The decision of MUST/SHOULD is up to the working group to recommend in
its
spec, and Jari will reflect that
Itojun,
[EMAIL PROTECTED] wrote:
MUST for HAO is self-contradictory at best. if HAO is a MUST, we don't
need bidir-tunnel (since it won't be used). if we have bidir-tunnel,
HAO is okay with SHOULD.
it is a MUST implement, not MUST use. you might not be able to use
Folks,
this discussion doesn't seem to be going anywhere at the point. Perhaps
we
can drop it?
The decision of MUST/SHOULD is up to the working group to recommend in
its
spec, and Jari will reflect that decision when he produces the final spec.
The consensus that has been recorded so
[EMAIL PROTECTED] wrote:
we are not arguing for SHOULD for HAO just because of conformance
(or because old KAME installations become non-conformant).
good.
we are arguing because we believe MUST for HAO has no technical
requirement (only political),
thats
Hi,
From: Vijay Devarapalli [EMAIL PROTECTED]
thanks Phil. this approach sounds good.
I agree, too.
We have had enough discussion and I am almost satisfied (though the
discussion have not closed yet, but this is not a prpblem). Many
people insist their opinion, almost all WG members hear
[EMAIL PROTECTED] writes:
If the intent is to support mobility in IPv6 networks as an integral
aspect of the protocol, I believe the HAO processing is a MUST. I
believe the Mobile IP WG is of this opinion.
That sure hasn't been my read of the consensus.
In fact, the consensus seems
Trimmed up the Cc: list a bit. I think this is getting way off topic
though..
On Mon, 22 Jul 2002, Kuntal Chowdhury wrote:
Here are two of the reasons why I think RO will be undesirable:
1. It allows the users to entirely bypass the home IP provider's network.
This will keep the home IP
On Mon, 22 Jul 2002, Kuntal Chowdhury wrote:
Here are two of the reasons why I think RO will be undesirable:
1. It allows the users to entirely bypass the home IP provider's
network.
This will keep the home IP network providers out of added revenue
streams.
The situation will
Hello Itojun,
i'm very concerned about the use of MUST for HAO since
mobile-ip6 draft 18 is trying to mandate new thing to all IPv6
(RFC2460) implementations.
SHOULD for HAO is okay for me, but MUST for HAO is unacceptable at
this stage of RFC2460-based IPv6
Title: RE: [mobile-ip] Re: HAO and BE processing will be mandated
Michael Thomas wrote: Frankly, I
don't think that there is any evidence that the
net would be substantially harmed if RO wasn't
widely implemented and/or enabled. Indeed, I
think there's good reason to believe that
Title: RE: [mobile-ip] Re: HAO and BE processing will be mandated
Hereare two of
the reasons why I think RO will be undesirable:
1. It allows the
users to entirely bypass the home IP provider's network. This will keep the home
IP network providers out of added revenue streams. The situation
Title: RE: [mobile-ip] Re: HAO and BE processing will be mandated
Hereare
two of the reasons why I think RO will be undesirable:
1. It allows
the users to entirely bypass the home IP provider's network. This will keep the
home
IP
network providers out of added revenue streams. The
you are both right. it was closed as 'Adopted' after there was concensus
on the mailing list. see, issue 45 at
http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html
it was reopened (unfortunately) as issue 53.
Vijay
Michael Thomas wrote:
[EMAIL PROTECTED] writes:
If the
Itojun,
there have never been any suboptions defined for the home address
option.
[EMAIL PROTECTED] wrote:
The home address option is the same in format as the
previous version. The additional requirement now is
only that now it's required to be secured somehow.
no it is not.
Itojun,
here are a little (incomplete) list of RFC2460-compliant
implementations that does not speak/understand HAO:
JunOS, ExtremeWare, MacOS 10.2, all FreeBSD since 4.0, all NetBSD
since 1.5, all OpenBSD since 2.7, Solaris beyond 2.7, Linux since 2.2,
there have never been any suboptions defined for the home address
option.
draft 07: type, length, an IPv6 address and suboptions,
type # = 196???
draft 08-16: type, length, an IPv6 address and suboptions, type # = 201
when there is no vaild sub-option defined, I would
draft 08-16: type, length, an IPv6 address and suboptions, type # = 201
draft 17-18: type, length and an IPv6 address, type # = 201
There is no difference. There were no valid suboptions defined for
earlier drafts, even though the field was shown as possibly there
for future suboptions. In
Pascal,
Face it: Many of today's large web servers will not want to
maintain binding caches.
We are not talking about forcing deployments to use RO, but
to have to code to support it have code to support the
HAO.
Think of it this way, this might always be a premium service
a web service
Michael,
I do not understand why you are insisting on SHOULD? If IETF is not
against having such MUSTs as in this case, let's have it. How can a
revolutionary technology such as MIPv6 allow HA reverse tunneling like
MIPv4 does?
Another benefit will be to mandate HAO in any new
* Just as an FYI, I replied to the earlier mail because I am
trying to sort this out for the node requirements. I think
that in MIPv6, it is OK that MIPv6 makes this recommendation (given
working group consensus, IESG approval, etc.) but the Node Requirements
document is the final word on
Title: RE: [mobile-ip] Re: HAO and BE processing will be mandated
Michael Thomas wrote:
Frankly, I don't think that there is any evidence
that the net would be substantially harmed if RO
wasn't widely implemented and/or enabled. Indeed,
I think there's good reason to believe that
Face it: Many of today's large web servers will not want to maintain binding
caches. Because:
- They are clustered (see my previous mail on this thread)
- Visits are short and unrelated (the caches are not reused)
- RR reduces the throughput and the response time
- They may even blindly accept
Pascal Thubert wrote:
Face it: Many of today's large web servers will not want to maintain binding
caches. Because:
- They are clustered (see my previous mail on this thread)
- Visits are short and unrelated (the caches are not reused)
- RR reduces the throughput and the response time
The
I'm sorry to raise this topic so many times, I still don't understand
the reason.
The current mip6 (draft-18) says that all IPv6 nodes:
- MUST be able to validate a HAO
- MUST be able to send a Binding Error message
I think I understand the benefit of the above requirements. If an
IPv6 node
we have no way to force upgrade for all users of the
existing IPv6
stacks. therefore, i believe it very important for
mobile-ip6 to be
defined so that:
- mobile-ip6 MN is interoperable with CN without HAO
support, nor
binding error message
as you may have heard during IETF54 IESG plenary panel session,
i would like to see the above MUST removed. there
are large amount
of IPv6 install base, which supports no HAO, or old
definition of HAO.
for instance, FreeBSD beyond 4.0 has IPv6 but no
support
From: Hesham Soliman (EAB) [EMAIL PROTECTED]
= Technically, removing the must on the HAO is not a problem.
In fact, regardless of deployed base, keeping a must for
the HAO makes no sense IMHO.
As for the BE message, I guess we need to make sure that
somehow the CN tells the MN that no
I'm sorry, I must describe more to complete the scenario.
From: Keiichi SHIMA / 島慶一 [EMAIL PROTECTED]
= Technically, removing the must on the HAO is not a problem.
In fact, regardless of deployed base, keeping a must for
the HAO makes no sense IMHO.
As for the BE message, I
I'm sorry, I must describe more to complete the scenario.
From: Keiichi SHIMA / 島慶一 [EMAIL PROTECTED]
= Technically, removing the must on the HAO is not a problem.
In fact, regardless of deployed base, keeping a must for
the HAO makes no sense IMHO.
As
hi Itojun,
[EMAIL PROTECTED] wrote:
as you may have heard during IETF54 IESG plenary panel session,
i would like to see the above MUST removed. there are large amount
of IPv6 install base, which supports no HAO, or old definition of HAO.
for instance,
[EMAIL PROTECTED] wrote:
it is. if a CN does not support HAO, it will send an ICMP error message
pointing to the offending octet. when the MN receives this message, it
starts reverse-tunneling through the Home Agent. where is the problem?
if this is not clearly specified in the MIPv6 draft,
[EMAIL PROTECTED] writes:
it is. if a CN does not support HAO, it will send an ICMP error message
pointing to the offending octet. when the MN receives this message, it
starts reverse-tunneling through the Home Agent. where is the problem?
if this is not clearly specified in the MIPv6
[EMAIL PROTECTED] writes:
it is. if a CN does not support HAO, it will send an
ICMP error message
pointing to the offending octet. when the MN receives
this message, it
starts reverse-tunneling through the Home Agent. where
is the problem?
if this is not clearly
Hi Michael,
then I see no reason for the MUST.
Sez RFC 2119:
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for
hi Hesham,
Hesham Soliman (EAB) wrote:
= Exactly, IMHO the support for HAO is tied to
RO support which is a SHOULD anyway, so the HAO
should follow that.
we have been through this before. the support for HAO is tied
to the verifiability of the home address (otherwise you can
have reflection
[EMAIL PROTECTED] writes:
Given that MIPv6 will interoperate without binding
code in CN's, it looks pretty much like a SHOULD
to me. Indeed, the protocol would not be robust if
it didn't consider the case of a non-conformant CN.
I think we want to ask is, is it the right thing to
Mike,
RO is a SHOULD, it is not a MUST in the current draft. we were
not talking about route optimization. we were talking about
processing a HAO. in the current spec HAO MUST be processed but
not accepted if it cant be verified. verification can be in the
form of checking for a valid BCE
Vijay Devarapalli writes:
RO is a SHOULD, it is not a MUST in the current draft. we were
not talking about route optimization. we were talking about
processing a HAO. in the current spec HAO MUST be processed but
not accepted if it cant be verified. verification can be in the
form
Bill Sommerfeld wrote:
have you read the latest MIPv6 spec?
I have, in fact read the spec.
there is an explicit code in the Binding Ack which says Route
Optimization unnecessary due to low traffic. the CN just has to
refuse the binding with this code.
So, existing nodes will
Hi Mike,
Vijay Devarapalli writes:
RO is a SHOULD, it is not a MUST in the current draft. we were
not talking about route optimization. we were talking about
processing a HAO. in the current spec HAO MUST be processed but
not accepted if it cant be verified. verification can be
= Exactly, IMHO the support for HAO is tied to
RO support which is a SHOULD anyway, so the HAO
should follow that.
Logically, you are inconsistant.
As an example, RO is a should, protecting RO is a MUST.
= Huh?
Protecting it is a must for those who support it!
[EMAIL PROTECTED] wrote:
processing a HAO is simply replacing the source address with
the contents of the HAO. earlier it is used to be a MUST without
the verification step. IPv6 WG was okay with that. but people
indentified some reflection attacks that are possible if you
blindly accept
i'm in violent agreement. HAO processing should not be a MUST.
HAO is not useful without verification and largely pointless unless
you're doing route optimization and can support a binding cache which
is large enough to be meaningful.
Given that there's already a way for a node to indicate
Hello Itojun,
The home address option is the same in format as the
previous version. The additional requirement now is
only that now it's required to be secured somehow.
Regards,
Charlie P.
[EMAIL PROTECTED] wrote:
processing a HAO is simply replacing the source address with
the contents
Hi Hesham,
= Exactly, IMHO the support for HAO is tied to
RO support which is a SHOULD anyway, so the HAO
should follow that.
Logically, you are inconsistant.
As an example, RO is a should, protecting RO is a MUST.
= Huh?
Protecting it is a must for
Title: RE: [mobile-ip] Re: HAO and BE processing will be mandated
Vijay,
I am missing something. Can we invent a new option in the future
and call it a MUST be processed by all nodes ? If a node does
not understand the option, it should use the icmp parameter
problem to return errors.
The question more is, what do general implementations need
to implement.
In my opinion, general often equals robust. SHOULD does not mean
optional, it means you do it unless you have good reason
not to do it.
I think the burden of proof, then, would be the endpoint
a new spec comes out. it has a lot of features. some of the
features are very important for the protocol (otherwise the
protocol does not work well). so we say all nodes have to
implement these features.
on the other hand, the new spec should not screw up the
earlier implementations.
are we
the point is this verification can be done in many ways.
but a correspondent node may only run services which won't benefit
from route optimization (i.e,. hit and run short exchanges typical
of a DNS server).
Let's assume the measured binding cache hit rate is 0% for a
particular server --
In your previous mail you wrote:
it is. if a CN does not support HAO, it will send an ICMP error message
pointing to the offending octet. when the MN receives this message, it
starts reverse-tunneling through the Home Agent. where is the problem?
if this is not clearly specified
it is nice to consider legacy nodes. But software upgrades
are also very routine. I dont have a machine which is running
the earliest version of Windows/FreeBSD/Linux/..
i don't think i have the same definition for legacy with you.
itojun
Bill Sommerfeld wrote:
the point is this verification can be done in many ways.
but a correspondent node may only run services which won't benefit
from route optimization (i.e,. hit and run short exchanges typical
of a DNS server).
Let's assume the measured binding cache hit rate is
have you read the latest MIPv6 spec?
I have, in fact read the spec.
there is an explicit code in the Binding Ack which says Route
Optimization unnecessary due to low traffic. the CN just has to
refuse the binding with this code.
So, existing nodes will reportedly refuse the binding with
A few issues have become mingled here.
1) Keiichi and others have raised the issue of MUST support for HAO
and BE processing and have proposed a solution that allows communication
to happen between any two nodes with clarification in the MIP spec of
properly handling the ICMP errors returned.
Hi Itojun,
we have no way to force upgrade for all users of the existing IPv6
stacks. therefore, i believe it very important for mobile-ip6 to be
defined so that:
- mobile-ip6 MN is interoperable with CN without HAO support, nor
binding error message
In your previous mail you wrote:
new-HAO?? the format has not changed. neither has the processing.
= this is not true, now the HAO must be verificable/verified.
infact, (IMO) there is no need for this new verification step if
we have smart ingress filtering as described by Francis
In your previous mail you wrote:
the point is processing of HAO gives you triangular routing,
which is much better than reverse tunneling.
= this battle was lost some months ago. You can even get some
people who don't believe the Internet is a metric space
(i.e., verifies the
In your previous mail you wrote:
I think that since HAO is used for security reasons, it may have a strong
need to be a must than other functionality. Just my opinion.
= I disagree: HAO is only a tunnel optimization and is *not*
used for security reasons.
[EMAIL PROTECTED]
Keith Moore wrote:
the purpose of a standard is to describe what is necessary for interoperability
and proper functioning of the protocol, not to legitimize existing
implementations. so the installed base shouldn't dictate whether a feature
is a MUST in a new version of a standard unless
Michael Thomas wrote:
I guess the long and short of this is that I'm
somewhat skeptical of putting general node
requirements in the MIP draft since it's
probably not the first place one would be
looking to figure out if they were an IPv6
compliant node. If it's really,
Vijay Devarapalli wrote:
new-HAO?? the format has not changed. neither has the processing.
it is still a destination option. how is it new? infact it has
been made secure by the new verification step.
The processing has changed in the sense that there is a new
verification step.
Pascal Thubert wrote:
* Just as an FYI, I replied to the earlier mail because I am
trying to sort this out for the node requirements. I think
that in MIPv6, it is OK that MIPv6 makes this recommendation (given
working group consensus, IESG approval, etc.) but the Node Requirements
document
Hi Pascal,
This issue seems to delay MIPv6 till the node requirement is
out;
I disagree. I think that MIP WG should specify what it thinks
is correct documents it. If the documentation is good
reasons are sufficient, I don't think that supportting it
in the Node Requirements document
[EMAIL PROTECTED] wrote:
Hi Pascal,
This issue seems to delay MIPv6 till the node requirement is
out;
I disagree. I think that MIP WG should specify what it thinks
is correct documents it. If the documentation is good
reasons are sufficient, I don't think that supportting it
in
Hi all,
I'm sorry to raise this topic so many times, I still don't understand
the reason.
The current mip6 (draft-18) says that all IPv6 nodes:
- MUST be able to validate a HAO
- MUST be able to send a Binding Error message
I think I understand the benefit of the above requirements. If an
78 matches
Mail list logo
