I agree. We can have an addendum API spec specifically for this later.
/jim
[Honor, Commitment, Integrity]
-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 19, 2002 10:46 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL
Sorry for the delayed response - didn't see me in the to: or cc: fields.
|In terms of the stability of the addresses one has to take into account
|both stability as it relates to local communication and stability for
|global communication.
We have always been told that stable global v6
The problem with this proposal is that the AP doesn't exist as far as IETF is
concerned. An AP is not an IP device, and it is not on the map as far as the
Internet architecture is concerned.. Routers do exist and therefore the fast RA
could be standardized in the IETF.
That said, I think the
The Host Requirements document is standards track, so I guess the
IPv6 Note Requirements should be standards track.
Not sure the logic works in this case. The HR doc includes
changes/updates to individual specs. I.e., it fixes things within
various specs that need fixing. In the case of this
Han wrote:
I agree with Richard.
The AP cahed RAs can be esaily implemented and an alternative to fast RAs.
IMHO, The AP which cache RAs and sends them to an MN at its association with the AP,
is more deployable approach than router supporting fast RA.
The change of AP is easier than the
Hi Thomas,
The Host Requirements document is standards track, so I guess the
IPv6 Note Requirements should be standards track.
Info/BCP would seem more appropriate. BCP might be OK and would
provide the stronger label.
As discussed at the meeting Monday, BCP seemed acceptable to most
MIPv6 does not say router should send RAs more frequently. it
just says access routers SHOULD be configurable to send RAs
more frequently. this is to be used in the absense of any L2
help.
Vijay,
One part of the problem I see is that your last sentence above doesn't
appear in the draft.
The ipForward table included ipForwardProto as part of
the index in RFC1354.
Why was the protocol field dropped from the index in RFC2096?
In the new draft inetCidrRouteProto is not part of the
index for the inetCidrRouteTable.
Different
For the disconnected site I think the site-locals work just fine, and
I haven't seen any strong arguments against using site-locals for
a disconnected site.
As many others have pointed out the complexity is not associated
with the case of the disconnected site.
Agreed, however my problem with
Today in v6ops I think I heard that compliance to the ND M bit being set
is optional. That I think is wrong. But the node reqs doc states that
dhcpv6 is unconditionally optional which is probably correct because
stateful may not imply dhcpv6 today. But if the M bit is set the host
node (non
I am still not clear on this because I didn't receive
any more replies ...
What do you do in the case where the host is multihomed?
Which interface do you use to send the packets?
I think it introduces more issues than what I think it tries
Erik Nordmark wrote:
One part of the problem I see is that your last sentence above doesn't
appear in the draft. Getting the applicability of the frequent unsolicited
RAs stated is important.
Doing this in a short separate draft doesn't have to delay the mipv6
spec, but working out the
James Kempf worte:
The problem with this proposal is that the AP doesn't exist as far as IETF is
concerned. An AP is not an IP device, and it is not on the map as far as the
Internet architecture is concerned.. Routers do exist and therefore the fast RA
could be standardized in the IETF.
The problem with this proposal is that the AP doesn't exist as far as IETF
is
concerned. An AP is not an IP device, and it is not on the map as far as the
Internet architecture is concerned.. Routers do exist and therefore the fast
RA
could be standardized in the IETF.
That said, I
Hi Jim,
Today in v6ops I think I heard that compliance to the ND M bit being set
is optional. That I think is wrong. But the node reqs doc states that
dhcpv6 is unconditionally optional which is probably correct because
stateful may not imply dhcpv6 today. But if the M bit is set the host
Not surprisingly, this reminds me of our discussion of Default Address
Selection. :-) Obviously, an application or device must have *some*
out of the box configuration.
Unfortunately there is a trade-off between security usability. One can
imagine several possible out of the box
James Kempf wrote :
The problem with this proposal is that the AP doesn't exist as far as IETF is
concerned. An AP is not an IP device, and it is not on the map as far as the
Internet architecture is concerned.. Routers do exist and therefore the fast RA
could be standardized in the IETF.
James Kempf wrote :
The problem with this proposal is that the AP doesn't exist as far as IETF is
concerned. An AP is not an IP device, and it is not on the map as far as the
Internet architecture is concerned.. Routers do exist and therefore the fast RA
could be standardized in the IETF.
James Kempf wrote:
snip
as i know, there are two 802.11 deployments : with relays APs and with
integrated AP/AR.
thus, i think this proposal(APs cache RAs) can be considered in IETF if
802.11 deployments with integrated AP/AR is considered. what do you think?
If the AP and AR are
So I listened to this argument for a very long
time (too long) yesterday wondering what on earth
the big deal was. I still don't get it. If people
want to dial up the ND rate, it only hurts their
link. There's no greater internet impact that I
can see. If it's taking up too much bandwidth, a
Hi Jim,
I find it hard to tell if you mean it is wrong (incorrect) or
wrong (not the right way to go).
about the current status though,
section 5.4.5 of RFC 2462 mentions that a node which receives the
M flag goes should undertake stateful address configuration.
there is no MUST
pyungsoo wrote :
As i know, APs are acting as link-layer relays, which means that they transport
Ethernet-layer frames between the wireless medium and the subnet.
In other words, APs don't provide the IP functionality.
Ok. I see.
Do you mean that APs should provide the IPv6 functionality to
First, site-locals offer better security than a single firewall, because
typically there will be multiple routers on the path between an attacker
and a customer site, all filtering site-locals. Second, I agree that
strong security is great and we should work towards it. But defense in
depth
Perhaps more importantly, I don't buy the argument that *any* set of
addresses should be considered trustworthy, by default or otherwise.
Addresses are simply not sufficient as an authentication mechanism.
This is not a practice that IETF standards should endorse or encourage.
I certainly
On Thu, 21 Nov 2002, Erik Nordmark wrote:
This assumes that ISPs will use site-locals. So far I haven't seen any
claims of benefits for ISPs to configure site boundaries and use site-local
addresses in their network.
If the ISPs don't use it the only boundaries would be at the attacker (which
Erik,
Richard Draves wrote:
First, site-locals offer better security than a
single firewall, because typically there will be
multiple routers on the path between an attacker
and a customer site, all filtering site-locals.
Second, I agree that strong security is great
and we should work
Please help me clarify the consequences of a SET operation
on the ipv6InterfaceAdminStatus specified in this draft, and
its relation to RFC2461 and RFC2462.
In RFC2462 section 5.3 , A node forms a link-local address whenever an
interface becomes enabled.
I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API
document. The following requirements in MIPv6 spec indicates that there
is a need for Socket API which will allow the MIPv6 applications to
choose
COA as mobile node's source address (in a visited network), while
default
address
In article [EMAIL PROTECTED] (at Wed, 20 Nov 2002 20:53:47 -0800),
Samita Chakrabarti [EMAIL PROTECTED] says:
My question is, if anybody in IPv6 working group is currently working on
such
API for default address selection draft ?
If not, I propose to add these APIs to the MIPv6 Advanced
YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Wed, 20 Nov 2002 20:53:47 -0800),
Samita Chakrabarti [EMAIL PROTECTED] says:
My question is, if anybody in IPv6 working group is currently working on
such
API for default address selection draft ?
If not,
30 matches
Mail list logo
