Hi Lorenzo,
The current text describes the meaning of "stale" as follows in 3.2.
The received information can be considered stale in several cases,
e.g., when the interface goes down, the DHCP server does not respond
for a certain amount of time, and the Information Refresh Time is
ex
-addr-select-opt-10.txt
has been successfully submitted by Arifumi Matsumoto and posted to the
IETF repository.
Filename:draft-ietf-6man-addr-select-opt
Revision:10
Title: Distributing Address Selection Policy using DHCPv6
Creation date: 2013-04-30
Group: 6man
Numb
All,
I compiled the suggested changes.
Thanks.
-
A new version of I-D, draft-ietf-6man-addr-select-
opt-09.txt
has been successfully submitted by Arifumi Matsumoto and posted to the
IETF repository.
Filename:draft-ietf-6man-addr-select-opt
Revision:09
Title
Address Selection Policy
Changes
Author(s) : Tim Chown
Arifumi Matsumoto
Filename: draft-ietf-6man-addr-select-considerations-05.txt
Pages : 18
Date: 2013-04-01
Abstract:
This ducument is intended to
Hi,
this issue was also discussed here in 6man.
Please refer to the following thread.
http://www.ietf.org/mail-archive/web/ipv6/current/msg13709.html
The result of the discussion was described in the past version of
the RFC 6724. But, it looks it was removed when it was re-structured.
Thanks.
t; In Abstract, suggest
> /allow nodes to select appropriate address/allow nodes to select an
> appropriate address/
>
> and s.2
> /POLICY TABLE OPITONS/POLICY TABLE OPTIONS/
>
> I think that that is all I had but will check again.
>
> Tom Petch
>
> - Original Message -
of the IPv6 Maintenance Working Group of the
> IETF.
>
> Title : Distributing Address Selection Policy using
> DHCPv6
> Author(s) : Arifumi Matsumoto
> Tomohiro Fujisaki
> Tim Chown
> Fi
e:
>> On 22 Oct 2012, at 10:00, Arifumi Matsumoto wrote:
>>
>>> 2012/10/17 Ray Hunter :
>>>> It's really a question of if we need to further clarify what is meant by
>>>> "default policy" in Section 4.2 of draft-ietf-6man-addr-select-opt
Brian,
2012/10/16 Brian E Carpenter :
> Hi,
>
> I support this draft but have a couple of comments.
>
>>A: Automatic Row Addition flag. This flag toggles the Automatic
>> Row Addition flag at client hosts, which is described in the
>> section 2.1 in RFC 6724 [RFC6724]. If t
Hi,
I received the following e-mail directly.
Let me add Cc to the list.
2012/10/17 Ray Hunter :
> inline.
>>
>> Arifumi Matsumoto <mailto:arif...@nttv6.net>
>> 16 October 2012 10:53
>>
>> Ray,
>> thank you for review and comments.
>>
>>
This should be removed.
Thanks.
2012/10/19 t.petch :
> s.7 IANA considerations request the allocation of a code for
> OPTION_ADDRSEL_ZONE
> Is this the now removed
> OPTION_ZONE_INDEX ?
> If not, what?
>
> s.2 "POLICY TABLE OPITONS"
>
> Tom Petch
>
>
> - Original Message -
> From: "Ole Trø
Ray,
thank you for review and comments.
Responses below.
2012/10/10 Ray Hunter :
> I support this work.
>
> Discussion
> ==
>
> Section 4.2
> s/the default policy should be restored/the previously active policy should
> be restored/ ?
It is assumed that the configuration will be either u
Karl,
2012/7/29 Karl Auer :
> A few days ago, I asked about this draft as below. I haven't seen a
> response, but the question still seems fair.
>
>> I don't fully understand this change (from section Appendix B):
>>
>> 1. Changed the definition of CommonPrefixLen() to only compare bits
>>
ect-opt, which is already informatively
>> referenced in the above text.
>>
>> -Dave
>>
>>
>
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/ma
Hi,
if an co-author has a right to vote :)
I like B.
If privacy address is attached, then it should mean it should be preferred.
On 2012/03/27, at 16:33, Brian Haberman wrote:
> All,
> The chairs would like to get a sense of the working group on changing the
> current (defined 3484) model
Hi,
On 2012/03/22, at 4:28, Brian E Carpenter wrote:
> On 2012-03-22 00:35, t.petch wrote:
>> - Original Message -
>> From: "Mark Andrews"
>> To: "Marc Lampo"
>> Cc: ; "'Brian Haberman'" ; "'Bob
>> Hi
t regards,
>
> You'll find the above logic in the current 3484bis draft.
>
> -Dave
>
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>
Brian,
2012/3/17 Brian E Carpenter :
> On 2012-03-16 23:30, Arifumi Matsumoto wrote:
> ...
>> Rather, my question was about the design choice.
>>
>> Regarding the design of ULA and how to use the ULA, can we agree that
>> ULA-to-ULA communication within the same /48
Dave,
On 2012/03/01, at 11:20, Dave Thaler wrote:
>> -Original Message-
>> From: Arifumi Matsumoto [mailto:arif...@nttv6.net]
>> Sent: Thursday, February 23, 2012 10:14 PM
>> To: Brian E Carpenter
>> Cc: Dave Thaler; Chris Grundemann; ipv6@ietf.org;
ge-ID:<20120215114010.14255.26519.idtrac...@ietfa.amsl.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the IPv6 Maintenance Working Group
&g
injection ?
This issue should arise also when a policy distributing mechanism
is ready.
Kindest regards,
On 2012/02/15, at 5:10, Brian E Carpenter wrote:
> On 2012-02-15 05:49, Arifumi Matsumoto wrote:
>> Dave,
>>
>> one quick question below.
>>
>> On 2012/0
Dave,
another point below.
On 2012/02/14, at 8:55, Dave Thaler wrote:
>> -Original Message-
>> From: Dave Thaler
>> Sent: Monday, February 13, 2012 2:01 PM
>> To: Dave Thaler; 'Chris Grundemann'; 'Brian E Carpenter'
>> Cc: 'ipv6@ietf.org'; 'Brian Haberman'; 'Bob Hinden'
>> Subject: RE: 6
Dave,
one quick question below.
On 2012/02/11, at 11:41, Dave Thaler wrote:
> I'm now working on an actual update to rfc3484 that would Obsolete
> (not Update) it. I found a couple more technical issues in so doing.
> I also now believe it's faster to do the replacement than it is to
> fix a d
Hi,
On 2012/01/23, at 16:09, Mark Andrews wrote:
>
> In message <43f32baa-c3cb-4214-bce7-b1cd75ec5...@nttv6.net>, Arifumi
> Matsumoto writes:
>> Mark,
>> thank you for your comment.
>>
>> As you mention it, it should be less harmful to give the whole UL
ff:feba:9a37 prefixlen 64 autoconf
> inet6 2001:470:1f00:820:218:f3ff:feba:9a37 prefixlen 64 autoconf
>>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
Arifumi Matsumoto
able was changed accordingly.
02:
Added the reference to address selection design team's proposal.
01:
The issue of private IPv4 address scope was added.
The issue of ULA address scope was added.
Discussion of longest matching rule was expanded.
robin.
The proposed changes section was re-structured.
The issue of 6to4/Teredo and IPv4 prioritization was included.
The issue of deprecated addresses was added.
The renewed default policy table was changed accordingly.
02:
Added the reference to address selecti
figuration option to use
the received policy on the untrusted interface, though.
Best regards,
>
> Thanks,
> Dmitry
>
> From: Arifumi Matsumoto [mailto:arif...@nttv6.net]
> Sent: Thursday, November 17, 2011 9:14 PM
> To: Dmitry Anipko
> Cc: ipv6@ietf.org
> Subject
Hi,
thank you for your comment.
On 2011/11/14, at 14:21, Dmitry Anipko wrote:
> Hello,
>
> I have a question about this text the -01 revision:
>
> >>A node MAY use OPTION_DASP in any of the following two cases:
> 1: The address selection option is delivered across a
>
Brian,
thank you for your comments.
On 2011/11/09, at 10:11, Brian E Carpenter wrote:
> Hi,
>
> I think I'm going to make myself unpopular.
>
> Reading this document as a proposed standard, I think it will confuse the
> reader.
> I think that what we actually need is a 100% replacement of RFC
aft-ietf-6man-rfc3484-revise-05.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
>>
>> Title : Upda
Hi,
I'm catching up an old thread.
On 2011/08/13, at 21:48, Philip Homburg wrote:
> In your letter dated Sat, 13 Aug 2011 12:17:29 +0200 you wrote:
>> I still think there's an issue with the suggested blanket global
>> treatment of IPv4 RFC1918 addresses.
>>
>> Quote draft-ietf-6man-rfc3484-re
ket.
So, in my understanding, the only restriction for using an
anycast source address was in RFC 3513. But, now that such a
restriction was removed, RFC 3484 should also be updated to
allow to select an anycast source address for a initiating
session.
--
Arifumi Matsumoto
NGN System Arch
And the corresponding distributing protocol format was already there in the
previous version. :)
http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-00
We just dropped this bit in the latest -01 version.
Best regards,
On 2011/07/27, at 5:37, Arifumi Matsumoto wrote:
> All,
>
&g
ension,
we need additional mechanisms like Label.
Or, any other implementation form ?
On 2011/06/29, at 14:28, Arifumi Matsumoto wrote:
> Hi Suresh,
>
> On 2011/06/29, at 4:32, Suresh Krishnan wrote:
>
>> Hi Tim,
>> There is already a programmatic switch for this in RFC5
---
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>
--
Arifumi Matsumoto
NGN System Architecture Project
NTT Service Integration Laboratories
E-mail: arif
>>>> Working Group of the IETF.
>>>>
>>>> Title : Update to RFC 3484 Default Address Selection for
>>>> IPv6 Author(s) : Arifumi Matsumoto Jun-ya Kato Tomohiro
>>>> Fujisaki Filename: draft-ietf-6man-rfc3484-revise-
to
> include ISATAP prioritization + DHCP(v6) distribution would likely be an
> extremely useful mechanism for controlling default end node behaviour in
> multinational companies (where AD may not be universally deployed). So keep
> up the good work in
> http://tools.ietf.org/html/draft-ietf
Mark,
On 2011/04/27, at 7:17, Mark Smith wrote:
> Hi Arifumi,
>
> On Tue, 26 Apr 2011 20:15:31 +0900
> Arifumi Matsumoto wrote:
>
>> Mark,
>>
>> in your case, policy table should be helpful to manipulate source
>> address selection behavior for SLA
. I think it'd be best to avoid something variable like most
> recently added/configured, so possibly something like using the
> numerically greatest interface id might be adequate.
>
> Regards,
> Mark.
> ----
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Admi
...@ietf.org]
>> On Behalf
>>> Of Teemu Kiviniemi
>>> Sent: Sunday, March 27, 2011 9:53 PM
>>> To: teemu.savolai...@nokia.com
>>> Cc: beh...@ietf.org; ipv6@ietf.org
>>> Subject: Re: RFC3484-revise and NAT64 Well-Known Prefix
>>>
>>>
Hi, Mikael, Hemant,
I think Mikael's concern is fair and it should be addressed clearer in this
document.
I agree that this rule is applicable when
- SLAAC is used for address assignment.
, or
- DHCPv6 server/relay is used for address assignment and it's on the router
sending RA.
Also, I under
Hi,
Sorry for replying to an ld thread.
A privacy address will also be generated for a ULA prefix,
because it is treated just like a global prefix, right ?
On 2011/01/04, at 4:30, Brian E Carpenter wrote:
> Pekka,
>
> Wouldn't the rule "Use ULA prefix inside the site and PA prefix (with
>
https://www.ietf.org/mailman/listinfo/ipv6
> ----
--
Arifumi Matsumoto
NGN System Architecture Project
NTT Service Integration Laboratories
E-mail: arif...@nttv6.net
TEL +81-422-59-3334 FAX +81-422-59-6364
---
Hi,
>> IMO, it's a matter of local network policy whether fe80::bad is
>> really good or bad.
>
> RFC 3484 with the default policy table already considers 6to4 source
> addresses worse than native addresses. I don't think it is
> controversial to similarly consider 6to4 routers as worse than na
Hi Tore,
On 2010/11/07, at 19:56, Tore Anderson wrote:
> * Arifumi Matsumoto
>
>> As I said, prioritization between IPv4 and IPv6 is a matter of
>> destination address selection, which my suggestion does not have any
>> effect on. Usually, native IPv6 is
Hi,
2010/11/1 Tore Anderson :
> Hello Arifumi,
>
> * Arifumi Matsumoto
>
>> On a host to which my suggestion is applied,
>> if the next-hop is 6to4 advertising host/router, then the source
>> address will be 6to4.
>> If the next-hop is native IPv6 adverting rou
Tony,
thank you for your draft.
IIRC, now that the address selection design team reached conclusion,
the 6man chairs have decided that the next step is to start discussion at 6man
ML,
and to compare each solution for the address selection problems.
I think this is a good start to look at Tony d
Hi,
On 2010/10/27, at 16:00, Ole Troan wrote:
>> Off the top of my head, I thought about a new rule to the RFC 3484.
>> It's really a simple rule, and seems to solve several problematic
>> cases related to address selection.
>> The rule is:
>>
>> Prefer to select an address as the source address
Hi,
thanks for sharing your concern.
My comments below.
On 2010/10/31, at 20:31, Tore Anderson wrote:
> Hi,
>
> * Arifumi Matsumoto
>
>> Off the top of my head, I thought about a new rule to the RFC 3484.
>> It's really a simple rule, and seems to solve several pr
ments ?
--
Arifumi Matsumoto
NGN System Architecture Project
NTT Service Integration Laboratories
E-mail: arif...@nttv6.net
TEL +81-422-59-3334 FAX +81-422-59-6364
IETF IPv6 working group mailing list
ipv6@ietf.org
Administr
t; It seems to me that very few of the references are actually normative.
> Most of them should be moved to "Informative".
Could you please tell me which ones do you think should be kept ?
--
Arifumi Matsumoto
NGN System Architect
e index, it means the zone index is 32bit length.
Of course, this does not mean other implementation uses 128bit scope id.
Best regards,
--
Arifumi Matsumoto
NGN System Architecture Project
NTT Service Integration Laboratories
E-mail: arif...@nttv6.net
TEL +81-422-59-3334 FAX +81-422-5
g list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>
--
Arifumi Matsumoto
NGN System Architecture Project
NTT Servic
way and go back further, in that we need to introduce
IPv6-NAT and also IPv4-IPv6 NAT. It seems to me that this going back
spoils what IPv6 is for.
> On 2010-07-30 04:22, Arifumi Matsumoto wrote:
>> All,
>>
>> at yesterday's bof, we had a lot of participants and good
Hi Brian,
On 2010/08/02, at 13:04, Brian E Carpenter wrote:
> Since I wasn't in Maastricht, let me give some quick answers:
>
> On 2010-07-28 17:44, Arifumi Matsumoto wrote:
>> Hi,
>>
>> At the yesterday's 6man session, the design team suggested three mai
some of the possible solutions.
On 2010/07/28, at 17:52, Arifumi Matsumoto wrote:
> All,
>
> the place and time is fixed for the bar-bof.
> http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78
>
> We welcome everyone to drop by.
>
> 20:00-21:30
> Multihoming with mult
All,
the place and time is fixed for the bar-bof.
http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78
We welcome everyone to drop by.
20:00-21:30
Multihoming with multiple prefixes without NAT66 : Implementation of
http://tools.ietf.org/html/draft-troan-multihoming-without-nat66. Live
d
Hi,
At the yesterday's 6man session, the design team suggested three main points.
Though it was decided to discuss more about this issue of address selection at
this mailing list, I'd like to see to how much extent those suggestions were
accepted by the 6man people *now*.
This is important, bec
Hi,
thank you for your comments.
2010/7/20 Fortune HUANG :
> Hi Tim,
>
> In section 7.3 of draft-ietf-6man-addr-select-considerations-02, the second
> paragraph reads:
> "It may of course be possible to piggy back policy information to a host in
> a Router Advertisement message, though initial co
RFC 3484.
The output was included in the existing revision proposal that
I had put together.
draft-arifumi-6man-rfc3484-revise-03.txt
We definitely need input from 6man people to move forward.
IETF IPv6 working group ma
em soon, then we will start seeing
> lots of deployment of IPv6 NATs.
As I mentioned above, the word "multihoming" may mean session survival
for not a few people, so in that sense, we may need different term.
Regarding NAT66-avoidance, we believe we need these mechanisms to
statement. This version includes all-at-once approach raised
by Fred Baker and the subsequent discussion in 6man ML.
* Considerations of address selection policy conflicts
http://tools.ietf.org/html/draft-arifumi-6man-addr-select-conflict-02
This one describes the merging process of
Hi,
On 2010/01/19, at 10:26, Brian E Carpenter wrote:
> Rémi,
>
> On 2010-01-19 01:46, Rémi Denis-Courmont wrote:
>> On Fri, 15 Jan 2010 20:13:16 +0900, Arifumi Matsumoto
>> wrote:
>>> * Fred's proposal.
>>> - A host tries each pair of src and dst
ad to user experience enhancement.
>>>> - Network side can have effects on dst address selection also.
>>>> ** Con
>>>> - Hosts have to have functionalito for receiving and
>> processing policy
>>>> information.
>>>&g
be implemented.
>>>> This does not always lead to user experience enhancement.
>>>> - Network side can have effects on dst address selection also.
>>>> ** Con
>>>> - Hosts have to have functionalito for receiving and
>> processing policy
on.
>> - To make use of routing information, routing information has to be
>> converted to address selection policy at intermediate nodes, and
>> frequently updatable policy distribution mechanism is necessary,
>> such as DHCP reconfigure.
>>
>>
>> * Co
Oops,
it looks like I failed the e-mail destination
address selection. X(
Best regards,
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-
松本の隔週報です。
* IETF/BBF方面
- Ciscoさん,沖本さんと進め方打合せ
- アドレス選択議論 6man MLで継続中。
- アドレス選択実装者に対してコンタクト。
競合回避方式について意見照会中。
- huaweiと情報交換テレカンの調整。
* NOC方面
- GoogleとJPNAPでピアリングセットアップ。
について問い合わせ中。
- cherry故障対策。
diamondとrubyのセットアップ。
- 大手町シリアル線収容替え。
- seattle故障対応。
- セキュリティポリシーの確認など。
* 岡田君関係
- 全国大会原稿提出
*
but if combined with
Fred proposal, the applicability will be broader.
So, my suggestion is to have both mechanisms, while keeping one mechianism
work without the other protocol.
--
Arifumi Matsumoto
Secure Communication Project
NTT Information Sharing Platform Laboratories
E-mail: ar
prefix length /32, /48 matching is
not always beneficial.
This is another motivation for distributing site local policy to the user hosts.
Regards,
Arifumi Matsumoto
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Fred,
On 2009/11/18, at 23:07, Fred Baker wrote:
>
> On Nov 18, 2009, at 7:43 PM, Arifumi Matsumoto wrote:
>
>> As I wrote in another e-mail, rather than giving over everything to hosts, I
>> think, giving hints for selecting addresses should be reasonable, at least
&g
Fred,
On 2009/11/18, at 18:50, Fred Baker wrote:
On Nov 18, 2009, at 6:43 PM, Arifumi Matsumoto wrote:
I'm not sure we can create perfect-in-every-environment
caching algorithm.
but you're convinced you can design an algorithm that consistently
out-thinks the network design?
On 2009/11/18, at 18:46, Fred Baker wrote:
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it
perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us not little impact.
If they space them
er experience, or provisioning cost.
For example, he may want to unload the traffic through CGN,
tunnel, translator middleboxes.
I'm not arguing that this approach is good or bad, but that
this approach fulfills all that we needed.
--
Arifumi Matsumoto
Secure Communication Project
have not tried to prototype.
Fred and operator running IPv6!
I am still interested about your opinion for UDP or multicast
applications with your approach and operational questions, burdens
enumerated in my previous e-mail.
Do we send ICMP error messages with all the source addresses,
ket interface would be
reasonably designed.
Caching implies some form of storage, which probably involves a
kernel API, which I have not tried to prototype.
Caching sometimes work nicely, and sometimes do harm.
I'm not sure we can create perfect-in-every-environment
caching algorithm.
--
are working on is not to make the host's decision better,
but provide a method for a network administrator to propagate
his policy to the client.
http://tools.ietf.org/html/draft-arifumi-6man-addr-select-conflict
"Considerations of address selection policy conflicts", Arifum
On 2009/11/10, at 10:58, Ralph Droms wrote:
In the discussion of IPv6 address selection , Dave Thaler asked me
to comment on this bullet from slide 10:
* DHCP option
- Hard to kick policy reconfigure by a server.
Not wanting to contribute to yet another iteration of the RA-vs-DHCP
debate
Erik,
On 2009/11/10, at 10:43, Erik Kline wrote:
If the latter paragraph only should be executed, the address given
by rogue RA remains, right ?
My reading would be that on receipt of a 0-lifetime RA that only the
second paragraph would be executed (lifetime timeout).
Second to that.
How
the latter paragraph ?
If the latter paragraph only should be executed, the address given
by rogue RA remains, right ?
On 2009/11/09, at 19:55, Yuji Sekiya wrote:
At Mon, 9 Nov 2009 19:52:48 +0900,
Arifumi Matsumoto wrote:
IIRC, routerlifetime and address lifetime is not correlated.
So, that
Hi,
I posted my draft revision, which discusses how to merge
conflicting address selection policies.
This revision includes a more concrete merging process.
I'm glad to have any comments.
http://www.ietf.org/id/draft-arifumi-6man-addr-select-conflict-01.txt
Kindest regards,
Ori
this separator should be configurable, what should be the
default ?
--
Arifumi Matsumoto
Secure Communication Project
NTT Information Sharing Platform Laboratories
E-mail: arif...@nttv6.net
IETF IPv6 working group
ments on this.
Best regards,
Begin forwarded message:
差出人: IETF I-D Submission Tool
日時: 2009年7月6日 16:23:17:JST
宛先: fujis...@syce.net
Cc: arif...@nttv6.net, hir...@inetcore.com
件名: New Version Notification for draft-arifumi-6man-addr-
select-conflict-00
A new version of I-D, draft-arifumi
t ignorant?
--
Aleksi Suhonen
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
----
--
Arifumi
Hi,
On 2009/06/23, at 16:19, Brian E Carpenter wrote:
On 2009-06-22 11:59, Arifumi Matsumoto wrote:
Hi,
On 2009/06/22, at 19:01, Brian E Carpenter wrote:
Hi,
Section 2.3 of draft-arifumi-6man-rfc3484-revise-01 says:
2.3. To change ULA address scope to site-local
RFC 5220 Section
Hi,
On 2009/06/22, at 19:01, Brian E Carpenter wrote:
Hi,
Section 2.3 of draft-arifumi-6man-rfc3484-revise-01 says:
2.3. To change ULA address scope to site-local
RFC 5220 Section 2.1.4, 2.2.2, and 2.2.3 describes address
selection
problems related to ULA. These problems can be
.
Because changing N means changing destination address selection
behavior for all the destinations in the Internet.
Kindest regards,
Arifumi Matsumoto
On 2009/06/22, at 18:48, Brian E Carpenter wrote:
Hi,
Sorry about the late reply. I agree with this (that is,
choice 3 in section 2.6 of draft
Hi,
just a quick comment.
On 2009/06/18, at 22:59, Aleksi Suhonen wrote:
Hi,
Arifumi Matsumoto wrote:
I found this is a very interesting proposal.
One question.
Thank you. I have one question too:
Should I submit the draft (after I write a bit more of it) for
discussion in Stockholm
org/mailman/listinfo/ipv6
--------
--
Arifumi Matsumoto
Secure Communication Project
NTT Information Sharing Platform Laboratories
E-mail: arif...@nttv6.net
IETF I
gt;
日時: 2008年6月19日 18:40:27:JST
宛先: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
件名: New Version Notification for draft-arifumi-6man-rfc3484-
revise-00
A new version of I-D, draft-arifumi-6man-rfc3484-revise-00.txt has
been successfuly submitted by Arifumi Mat
,
Arifumi Matsumoto
On 2008/06/04, at 13:20, Brian E Carpenter wrote:
> Joe,
>
>> It seems to me that direct assignment could quite possibly become the
>> default for small IPv6 sites in the ARIN region. IPv6 uptake to
>> date has
>> been so tiny that I don't think
implemented by using RFC 5014 or
its extension.
Anyway, these issues should be fixed by revising RFC 3484 itself
I believe.
Kindest regards,
Arifumi Matsumoto
On 2008/06/03, at 20:20, Rémi Denis-Courmont wrote:
>
> Hello,
>
> On Tuesday 03 June 2008 13:44:26 ext Ruri
Hi,
> I suggest the same to the authors of
> draft-ietf-6man-addr-select-sol-00.txt. Could you please first describe
> what is the problem with SAS as specified in RFC 3484.
>
> Hemant
sorry for the looong delay,
As stated in this document section 1,
Today, the RFC 3484 mechanism is widel
e ready to welcome this proposal if this is
accepted by ipv6 people.
I'd like to have everyone's comments on moving this mechiansm forward
to dhc working group.
--
Arifumi Matsumoto
IP Technology Expert Team
Secure Communication Project
NTT Information Sharing Platform Lab
Folks,
so, can I re-submit this item as an 6man wg item ?
For -00 version, I'm not going to make any change to this document.
Kindest regards,
Brian Haberman wrote:
6MAN WG,
The consensus in Vancouver was to adopt
draft-arifumi-6man-addr-select-sol-00.txt as a WG document. The c
Hi,
from this minutes I couldn't tell my document was adopted
as 6man wg item. At Vancouver, I believe, my sol document
was adopted as 6man wg item. Is that correct ?
Sincerely yours.
Address Selection (2 presentations)
==
Document: draft-arifumi-6man-addr-selec
Hi all,
I've sent the following e-mail to 6man chairs, but I have
no response so far. So let me re-send it to the ML.
I want to cover quickly the summary, history and updates
of our item.
Thanks.
-
Date: Sat, 24 Nov 2007 02:09:35 +0900
From: MATSUMOTO Arifumi <[EMAIL PROTEC
rom the on-line Internet-Drafts
directories.
Title : Solution approaches for address-selection problems
Author(s) : A. Matsumoto, et al.
Filename : draft-arifumi-6man-addr-select-sol-00.txt
Pages : 17
Date: 2007-11-8
y I-D,
because intarea is for RAM this time at 68th IETF. :(
Comments below.
From: Brian E Carpenter <[EMAIL PROTECTED]>
Date: 2007/03/06 1:21
Subject: Re: I-D ACTION:draft-arifumi-ipv6-rfc3484-revise-00.txt
To: IPv6
2.4. To make address type dependent control possible
...
For example,
1 - 100 of 112 matches
Mail list logo
