Re: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt
Ole Troan <otroan@employees.org> Fri, 20 February 2015 10:41 UTC
Return-Path: <otroan@employees.org>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C221A883D for <softwires@ietfa.amsl.com>; Fri, 20 Feb 2015 02:41:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_wF7rBHibt3 for <softwires@ietfa.amsl.com>; Fri, 20 Feb 2015 02:41:34 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974E61A882B for <softwires@ietf.org>; Fri, 20 Feb 2015 02:41:34 -0800 (PST)
Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 063F56164; Fri, 20 Feb 2015 02:41:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=xVJAf5ALWI1uBJI8az3ao6zvGPk=; b= RCs8Ty+NHq/v0GUAfEYggkEPjfCpFlJK+Po2dFh8V+9RbSFy98BOguXGWIHqzOHr A3rz6NKMVEHNv7SatTkSH/GBKMK3g4o//cMN5cl8AWCYn7FnQMA/5/bKdHDjj4Sj owhWMukL1fhaEUNqtQNlLq2YskFlm/9WsGrimphAX7w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=IN1UbnfTDL4VOQrb4zP3eWLuil KVCAQYmkHda595TCi2sXtFZtYsiUr7ECLqlfzR8F78SsGh8z5RnqSUwo+jxZ7YXs 0sGtlGItVUs1z5ImUCOaez4D7xdSfIIZLbus6tkbcICTbhL7HTvUP/o+TPkiPsip l+jNocK7Tv98HXO7E=
Received: from gomlefisk.localdomain (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 7F31760FF; Fri, 20 Feb 2015 02:41:32 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id 4A6B83F12146; Fri, 20 Feb 2015 11:41:30 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_B2EA86FB-D85A-40DB-B2A2-73192DD7A725"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5b5
From: Ole Troan <otroan@employees.org>
In-Reply-To: <54e056b8.0d886b0a.535d.ffffcb06@mx.google.com>
Date: Fri, 20 Feb 2015 11:41:29 +0100
Message-Id: <E56786E3-FE1C-4961-A0A1-408B5BAF0854@employees.org>
References: <20141124073912.16300.97956.idtracker@ietfa.amsl.com> <54e056b8.0d886b0a.535d.ffffcb06@mx.google.com>
To: Leaf Yeh <leaf.yeh.sdo@gmail.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/softwires/iAuYIgoCUvhtLDII_7YGnqZD80s>
Cc: softwires@ietf.org
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2015 10:41:36 -0000
Leaf, > I got a late read on this draft, and may find some editorial nits: > > #1. In sec. 3, > " End-user IPv6 prefix: The IPv6 prefix assigned to an End-user CE by > other means than MAP itself. E.g., > Provisioned using DHCPv6 PD [RFC3633], > assigned via SLAAC [RFC4862], or configured > manually. It is unique for each CE. " > > Q. Does the above means ' End-user IPv6 prefix ' includes 's bits' (the subnet ID) in Fig.3? no, it is e.g. the /56 delegated to the end-user. > But in sec. 5.2, > " The MAP IPv6 address is created by concatenating the End-user IPv6 > prefix with the MAP subnet identifier (if the End-user IPv6 prefix is > shorter than 64 bits) and the interface identifier as specified in > Section 6. " > > Q. Does the above means ' End-user IPv6 prefix ' does not include 's bits' (the subnet ID) in Fig.3? I guess we could include 's bits' (the subnet ID= MAP subnet identifier) into ' End-user IPv6 prefix '. correct, the subnet-id is not included in the End-user IPv6 prefix. the End-User IPv6 prefix is the "name" for the address block that the ISP gives to the subscriber. > And in sec. 6, > " If the End-user IPv6 prefix length is larger than 64, the most > significant parts of the interface identifier is overwritten by the > prefix. " > > Q. Does the above means ' End-user IPv6 prefix ' includes 's bits' (the subnet ID) in Fig.3? still not. > #2. In sec. 5.1, > " For 'a' > 0, A MUST be > larger than 0. This ensures that the algorithm excludes the > system ports. For the default value of a (6), the system ports, > are excluded by requiring that A be greater than 0. Smaller > values of a excludes a larger initial range. E.g., a = 4, will > exclude ports 0 - 4095. The interval between initiaL port numbers > of successive contiguous ranges assigned to the same user is > 2^(16-a). " > > I prefer the above sentence could be > " For 'a' > 0, 'A' MUST be > larger than 0. This ensures that the algorithm excludes the > system ports. Smaller > values of 'a' excludes a larger initial range; e.g. 'a' = 4, will > exclude ports 0 - 4095. The interval between initial port numbers > of successive contiguous ranges assigned to the same user is > 2^(16-a). " I agree that we should tag 'a'. I'll add that. > #3. In Fig.7 of sec. 5.3, > “ +----------+ +------------+ > |IPv4 sufx| |Port-Set ID | > +----------+ +------------+ ” > I prefer the above ‘sufx’ could to be ‘suffix’. ack. > > #4. In sec.6, > “ The PSID field is left-padded to create a > 16 bit field. For an IPv4 prefix or a complete IPv4 address, the > PSID field is zero.” > > Q. Does the about ‘zero’ means the value of the PSID=0x 00, or the length of the PSID is zero? I guess it means the former, right? correct. > #5. In Fig.8 of sec.6, > “The Interface identifier format of a MAP node is described below. > | 128-n-o-s bits | > | 16 bits| 32 bits | 16 bits| > +--------+----------------+--------+ > | 0 | IPv4 address | PSID | > +--------+----+-----------+--------+ ” > > I think BR does not need to use the above IID. I prefer to replace the word ‘MAP node’ to be ‘MAP CE’. Right? correct, but that leads us back to the discussion if the BR should be part of the MAP domain or not. that is should it be possible to reach an address of the BR using IPv4. that's why it says MAP node instead of MAP CE. > The above format looks like ‘128-n-o-s =64, but that is not always true. I prefer the IID format of MAP CE could be: > | 128-n-o-s bits | > | <=16 bits| 32 bits | 16 bits| > +--------+----------------+--------+ > | all 0s | IPv4 address | PSID | > +--------+----+-----------+--------+ ” whenever we speak about an IPv6 Internet ID it is 64 bits long. I'd rather not that we change that here. I do see what you are saying though. > #6. In sec. 8.1, > “ Secondly, the node extracts the source IPv4 > address and port from the IPv4 packet embedded inside the IPv6 > packet. If they are found to be outside the acceptable range, the > packet MUST be silently discard and a counter incremented to indicate > that a potential spoofing attack may be underway.” > > I guess the better to substitute the above word ‘embedded’ could be ‘encapsulated’, right? yes, thanks. > > #7. In sec. 11 > “ They cannot > exist with MAP because each BRs checks that the IPv6 source > address of a received IPv6 packet is a CE address based on > Forwarding Mapping Rule. ” > > I think BRs check that the IPv6 source address of a received IPv6 packet is a CE address based on Basic Mapping Rule, and check that the IPv6 destination address of a received IPv6 packet is a CE address based on Forwarding Mapping Rule, right? no, the destination IPv6 address is the BR address, and there is no point checking that. cheers, Ole
- [Softwires] I-D Action: draft-ietf-softwire-map-1… internet-drafts
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Leaf Yeh
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Ted Lemon
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Leaf Yeh
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Leaf Yeh
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Leaf Yeh
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Ole Troan
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Xing Li
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Leaf Yeh
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Leaf Yeh
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Leaf Yeh
- Re: [Softwires] I-D Action: draft-ietf-softwire-m… Ole Troan